This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWRL6432: Two serial ports open at the same time to read data, will read the serial data

Part Number: IWRL6432
Other Parts Discussed in Thread: IWR6843, SYSCONFIG

Consult a question about serial port. Two serial ports of radar are needed in the project, one is used to communicate with external MCU, and the other is used for debugging. Each serial port should support data reading and writing. By creating two tasks for serial reading, each with a priority of 1, similar to CLI_task. In two ways;
Mode 1: The serial port adopts the polling method, and two reading serial data tasks open at the same time will lead to incomplete data reading, and it is easy to lose packets. If only one reading serial data task is started, there is no problem of incomplete data reading and unable to read.
Mode 2: The serial port adopts the mode of interrupt blocking, and two reading serial data tasks can be opened at the same time, and there will be no problem of data not being read. With the need of external MCU through serial port with radar real-time communication, frequent mmwDemo_TransmitProcessedOutputTask after running for a period of time serial data output is suspended in the task, at this time send the CLI command can be normal receive radar. Whether frequent interruptions caused mmwDemo_TransmitProcessedOutputTask no data output the serial port. The main problems of the above two serial port methods are; The method of polling can not read the complete data, and the packet loss rate is high, which can only support one way of serial port data reading. With the method of interrupt, can support both road serial data read won't lost package, but will cause mmwDemo_TransmitProcessedOutputTask no serial data output. Please guide me on these two questions. thank you.

  • Hello, 

    Thanks for your post. I am looking into your questions and will reply tomorrow. Your patience is appreciated. 

    Best Regards,

    Josh

  • Josh,

    Few more information for your reference.

    In mmw demo UARTB (RS232TX/RX) is configured, customer add one another UARTA working as polling mode, change the SW as the mmw demo to start one another client task with same priority for UARTA to do data transceiver. The two UARTs use polling mode to receive data from outside. In real test the data is sent to the uartA and B at different time, so actually the two uart would not receive data at same time. In this case i think it should be able to work. But in customer test sometimes would miss data. 

    The same method has ever been tested on IWR6843, and it would fine.

    it has blocked customer's project production time, your comments is welcome, look forward to your reply, thanks.

    Andy

  • Hi Andy, 

    Thanks for the additional information. 

    I still have some slight confusion around the customer's current tests and results so let me ask a few questions.

    1. In the current tests data is being sent to UARTA and UARTB at the different times but still some data is missed. Is this correct?
    2. The customer has added UARTA through sysconfig configuration, correct? It would be helpful to know the details of the UARTA configuration besides polling mode, for example what is the baud rate for UARTA?
    3. Have any of the details of the UARTB configuration been changed or they remain the same?
    4. When data is missed, is it only ever missed from UARTA or can be missed by either/both UARTs?

    Best Regards,

    Josh

  • Hi Josh,

    Let me answer your questions.
    1. When I only send data to one serial port or send data to two serial ports at the same time in the test, the data will be incompletely received or not received. However, turn off the reading of the other serial port, and there is no problem of missing data or not being able to read.
    2. I configured UARTA through sysonfig, the baud rate is 115200, as shown in the figure;
    3. The configuration of UARTB has not changed.
    4. Two serial ports will appear data loss, data can not be read. The probability of data loss is above 50%.

    Best Regards,

  • Hi,

    Thank you for this information. Can you try selecting the UARTA/UARTB in sysconfig instead of letting them be the "Any" value? Does that change the behavior?

    Best,

    Nate

  • hello.

    When you change it to Any, the effect is the same as before.

  • Hi,

    I would suggest u configure the debug UART as interrupt mode, keep the data UART as polling mode, and have the data UART task with lowest priority, pls have a try.

    One workaround, If the two UARTs are not used same time, u can try to enable only one UART once, while disable the other.

    Andy

  • Thanks Andy. Please let me know if you were able to try Andy's suggestion. 

    Best Regards,

    Josh

  • HI.

    According to Andy's suggestion, configure the debug serial port in interrupt mode and the data serial port in polling mode. The priority of data task is the lowest, and the priority of debugging serial port task is higher than that of data task. In this way, both serial ports can receive data normally. Thank you very much for your support of this work

  • Hi.

    In a data interaction test at regular intervals of 100ms, it is found that the serial interface task using interrupt mode can not read data after a few minutes of testing, while the serial interface task using polling mode can read data. The priority of the task using the interrupt serial port is 2, while the priority of the task using the polling serial port is 1.

  • Hello, 

    Can you please help me understand what you mean by "data interaction test"? What data is being sent/received? Also does the device seem to be crashing entirely or just that input data is no longer read? Also when data is no longer read, is it consistently happening at the same time or just sporadically after a few minutes of running?

    Best Regards,

    Josh

  • Hello.

    The data interaction test can be understood as: send data to the radar every 100ms, and the radar sends reply data immediately after receiving the data. Test data interaction with interrupt mode the serial port of the task, in mmwDemo_TransmitProcessedOutputTask () at the same time, serial printing frame to two road (frame time 100 ms), each run after 3 minutes or so will appear the following phenomenon. Phenomenon 1: Neither of the two serial port channels can receive data, and the radar does not output frame number, just like hanging down. Phenomenon 2: The task in interrupt mode cannot read the input data, and the serial port in another polling mode can receive the data, and the radar outputs the frame number. The above two phenomena, basically every test will appear one of the phenomena. When the test data interaction is carried out using the polling mode serial port task, the above problems do not appear. Reading input data in interrupt mode can cause some unexpected problems. The polling mode is relatively stable, and in the past 1843, 6843 platforms are all using the polling mode.

  • Hi,

    Thank you for the information. I'm trying to investigate what the potential issues could be. Please give me a day or two to get back to you. 

    Best regards,

    Josh

  • Hi,

    I noticed UART issue in the errata, that 115200 is not supported now, there would have error rate, suggest use 1.25Mbps. Details can be found in the page9 of below link. Pls change the baud rate for try, thanks.

    https://www.ti.com/lit/er/swrz149/swrz149.pdf?ts=1700116016664&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FIWRL1432%253FkeyMatch%253DIWRL1432%2526tisearch%253Dsearch-everything%2526usecase%253DGPN

    Andy

  • Hi.

    The baud rate has been changed to 1.25M, so the problem takes a bit longer to reappear, but it's still the same as before. Because baud rate only affects data errors, and I feel that it is caused by interrupt mode, but it is still normal in polling mode.

  • Hello, 

    I understand that changing to the higher baud rate does not eliminate the issue. I'm still looking into potential causes. I will update you here tomorrow. Your patience is appreciated. 

    Thanks and regards,

    Josh

  • Hello, 

    I'm very sorry for the delay here. From our side there are no known issues that should be causing this behavior. 

    In effort to debug further can you run the example via CCS? You can follow the steps in this CCS Debugging guide. When both phenomena occur can you pause the execution in CCS so we might see if the device has crashed or is hanging somewhere?

    Best Regards,

    Josh

  • HI.

    When the serial port is configured in polling mode, the ccs debugging results show that sometimes the serial port data reading task cannot be accessed. If only one serial port data reading task is enabled, the serial port data reading task cannot be accessed after data is sent. I think the data cannot be read or is incomplete when the two serial ports are opened, which should be caused by the mutual interference between the two serial port reading tasks.

  • Hi, 

    How are you confirming that the data reading task is not being accessed? Are you using breakpoints in CCS? 

    When the serial port is configured in polling mode, the ccs debugging results show that sometimes the serial port data reading task cannot be accessed. If only one serial port data reading task is enabled, the serial port data reading task cannot be accessed after data is sent.

    Can you please clarify your meaning here? Do you mean that both serial ports are opened but data is only being sent on a single port and still the data is not received from the device side?

    Best Regards,

    Josh