Debugging serial port problem of S32G2 M core

[jack_huang1]

Dears,

The product solution is S32G274. Currently, LINFlexD_0 is used as the debugging serial port of core A. LINFlexD_0 used by core A is not abnormal. LINFlexD_1 is the debugging serial port of M core. The problems in M core are as follows:

Since the project requires sending and receiving data at the same time without affecting the real-time output of debug logs, we need the serial port to have the full-duplex feature and non-blocking interface. These all meet the conditions in the manual, but do not match the manual in the actual test.

At present, the debugging serial port of M core mainly has three problems:

1. Linflexd_Uart_Ip_AsyncReceive function is blocked (inconsistent with the asynchronous feature of the interface).

The tested serial port data receiving interface is Uart_AsyncReceive, which calls Linflexd_Uart_Ip_AsyncReceive. This interface is described as a non-blocking interface as follows:

But in real tests, the interface is blocked after running until the data received reaches a specified length. The non-blocking feature is different from that described in the manual.

1. Uncached data at the bottom of data receiving leads to the loss of received data beyond the set buffer

In the test, when the actual length of sent data is larger than the set length of received data, the data exceeding the set length will be lost. The Uart_SetBuffer interface is used to solve the problem. The interface is described as follows:

The test found that the interface could not solve the problem of data loss.

1. Failure of the sending interface during serial port data receiving. (Does not conform to full duplex characteristics)

The current sending interface is Uart_AsyncSend. This interface calls the Uart_StartAsyncSend function. The internal logic of this function is as follows: When data is being received, the sending stops.

Therefore, we cannot send and receive data at the same time, which is different from the full-duplex feature described in the manual.

 Please check them. Whether it can only be set to LINFlexD_0 as the debugging serial port of M core? How to adjust?  Thank you very much!

[DylanZhao]

Hi Jack:

Recently, I have been debugging UART1 on M core and met the same problem as you. Uart_AsyncSend and Uart_AsyncReceive interfaces block each other when one of them is transmitting, I want to implement the full-duplex work of sending and receiving messages at the same time. Have you solved the problem?

[Daniel-Aguirre · Accepted solution]

Hi,

Below will be some comments on the points mentioned:

1. Linflexd_Uart_Ip_AsyncReceive function is blocked (inconsistent with the asynchronous feature of the interface).

1a. As you are saying "...the interface is blocked after running until the data received reaches a specified length...". As said in the S32G RM:

"The reception is automatically completed as soon as the programmed number (RDFL bits) of bytes have been received." [Chapter 48.4.4.5 UART receiver, Page 2216, S32G2 Reference Manual, Rev. 5, 05/2022].

The recommendation is the following:

"If you do not know in advance how many bytes are to be received, RDFL must not be programmed in advance. The reset value of RDFL is 0. This ensures that the reception happens byte by byte. The state machine moves to the Idle state after each byte reception." [Page 2217, S32G2 Reference Manual, Rev. 5, 05/2022].

2. Uncached data at the bottom of data receiving leads to the loss of received data beyond the set buffer.

2a. In case of the buffer, this is used as the input register for the RX channel. As said in the RM "LINFlexD has a dedicated data buffer for received data. This buffer comprises 4 bytes if UARTCR[WL1] = 0 or two half-words if UARTCR[WL1] = 1." [Page 2216, S32G2 Reference Manual, Rev. 5, 05/2022].

You can store a maximum of 4 bytes (or 2 halfwords) within the provided buffer (BRD4-7).

3. Failure of the sending interface during serial port data receiving. (Does not conform to full duplex characteristics)

3a. At this moment, we cannot locate the function you are using for transmit operation (Uart_AsyncSend), could you please help us with telling what version of the RTD are you using?

Unless you stop the transmission prior to uploading to the transmit buffer, once the data is in the buffer, no stop should be happening.

Please, let us know