Posts by mbazdar

    Hello,


    Thanks for the help.


    I have now enabled I2C bus drivers through Catalog items, and RTC started working.


    Can you please confirm that we will still be able to use UART E when I2C is enabled, since UART E lines are shared with I2C?


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    I have disabled I2C drivers in our custom image, since we do not use I2C peripherals. That is the reason why RTC haven't kept the correct time. I have now enabled I2C bus drivers through Catalog items, and RTC started working.


    Can you please confirm that we will still be able to use UART E when I2C is enabled, since UART E lines are shared with I2C?


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    On our efusA9X board implementation we have applied battery supply (voltage level about 3.15V) on pin 9 of efusA9X, as suggested in hardware design guide. We still cannot get correct time after power restart. I mean, we set correct time and date using date/time commands, but after power restart, date is reset to Sunday, January 01, 2006. year.


    Do we miss something some RTC related setting in the configuration, or a kind of forcing write to system clock?


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    Thanks for the swift response. I confirm that your beta version works. RTS line is correctly toggled when data is ready to be sent.


    Can you please make this correction general, so we could have serial driver which supports RTS_CONTROL_TOGGLE on all available UARTs (for example, we will need it for UART C on efusA9X without BT and UART E as well).


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    I am opening new thread since this issue is not related to the thread "UART C on efusA9X with on board WLAN/BT" where we have started the discussion about it.


    So, the problem is that hardware flow control is not supported at all (as it seems) by serial driver on efusA9X. Here is what I have observed while running tests on our hardware and using oscilloscope to monitor UART lines. Tests were done on UART B, using lines 102, 104, 106 and 108 on efusA9X. I have tried all variants of RTS flow control mentioned in fRtsControl member of DCB structure (RTS_CONTROL_ENABLE, RTS_CONTROL_DISABLE, RTS_CONTROL_HANDSHAKE, RTS_CONTROL_TOGGLE). No matter what flow control I used, both RTS and CTS lines were on low level all time. Serial driver does not seem to drive RTS/CTS at all. I confirm I had correct data output on Tx line during the test. Moreover, I could drive RTS/CTS manually (using ioctls from dio_sdk.h), so, I confirm that I have monitored correct lines.


    I have also tried to use RS485=1 (REG_DWORD) registry value in HKLM\Drivers\BuiltIn\efusA9X\UARTx, although I am not sure what is it meant for, or if it is supported at all. It did not make any change, nevertheless.


    Can you please check and correct this issue in some priority? For us, RTS_CONTROL_TOGGLE is the feature of interest. Currently, we are not interested in other flow control modes.


    Thanks in advance.


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    I am not sure I understand you. You say RTS_CONTROL_TOGGLE should work, but there is a bug in the driver. It cannot work then, right? Or you meant to say it will work, but it will drive CTS line instead of RTS?


    Best regards,


    Miodrag Bazdar

    One more thing, please.


    What is the meaning of registry value RS485 (REG_DWORD) in driver for Serial I/O (UART)?


    Is RTS_CONTROL_TOGGLE flow control supported by serial driver on efusA9X? Our RS485 interface is using three lines: Rx, Tx and RTS which is used to select direction of data transmission.


    Thanks in advance.


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    We have efusA9X boards with on board WLAN/BT module. We are not using BT, so we have disabled support for it in BSP, and tried to use UART C to interface RS485 port on our hardware. After modification in BSP, I am able to open COM port related to UART C, I can even send the data from program on this COM port and read it on our RS485 port, so sending data is working. The problem is I cannot read data on UART C.


    Please tell me if this configuration is possible and, if it is, what should I do to make reading possible?


    Thanks in advance.


    Best regards,


    Miodrag Bazdar

    Hello again,


    I have modified our image as per your instructions. Fifth UART appeared in the system, I can open and close it from program, no errors appear on serial debug, so hopefully it will work at once. For full test we have to wait for our modifications in hardware though.


    Thanks for now,


    Best regards,


    Miodrag Bazdar

    Dear Support Team,


    Thanks a lot for such a swift response. We'll have to make some hw modifications as well in order to test the driver, so, as soon as we manage to do it, I will provide feedback from our side.


    Thanks again,


    Best regards,


    Miodrag Bazdar

    Dear Suport Team,


    Can you please tell me if it is possible to use UART E on efusA9X (pins 126 and 86) if we don't don't use it for default purpose? You mention in hardware documentation that:


    UART_E, UART_F and UART_D control are pin sharing options and need special software

    support. This functionality is not available on other efus boards and is not available on F&S

    evaluation baseboards.


    Does this mean that we need some special BSP from you if we need to use UART E as the fifth UART on efusA9X?


    Thanks in advance.


    Best regards,


    Miodrag Bazdar

    Hello,


    Thank you for the latest BSP. I confirm that after running tests during last 5 days we didn’t encounter any WLAN crash. Furthermore, connection seems to be more stable and faster, both in 5GHz and especially in 2.4GHz band. I hope we can finally close this case.


    Best regards,


    Miodrag Bazdar