Uart Module of S32G274 Chip Callback Event: LINFLEXD_UART_IP_EVENT_IDLE_STATE mechanism Problem

[KeithWANG]

  As shown in the figure above, we see the Uart module timeout related functionality in the Uart module UM. So we Enable the function of "Uart Timeout Enable", generate the configuration file, compile and run in the project.

  Within the project, we enable the "Uart Callback Capability" option, using a custom Callback function, where the Callback parameter Event is the enumerated type defined by the Uart module:

、

  At the same time, the data on the Uart channel is sent at a frequency of 1Hz. Through Lauderbach debugging, we find that after the program starts running, the program triggers an interrupt of the event LINFLEXD_UART_IP_EVENT_IDLE_STATE and enters the Callback function. Uart then stops updating the data and looks at the register as follows:

  Then, we do the corresponding processing under the event, found that when the event is triggered, re-call "Uart_AsyncReceive" function, so that the Timeout event is rolling triggered;

  Can we understand the timeout mechanism of uart as follows:
  When the Uart channel receives a frame of data, if the Uart is idle, the register UARTCTO will increase one by one. When the UARTCTO is equal to the preset register UARTPTO, the timeout event will be interrupted and RxEn register will be disabled, and the Uart will not actively resume the receiving state. If the Uart_AsyncReceive function is called again after the received data is processed, and the Uart is still idle, it will enter the timeout interrupt again.

  We don't know if the chip's Uart mechanism is as we guessed. If not, please correct, so that we can better achieve business function.

  We hope that the timeout mechanism of the Uart is as follows: The timeout interrupt only notifies the Uart when it changes from busy to idle. And you don't need to call the Uart_AsyncReceive  function again. In this case, the relevant interrupt is triggered. In this way, we can process the current frame data received when the interrupt is triggered, providing real-time data transmission.

Hope NXP can have an expert answer, thank you!

  如上图所示，我们在Uart模块的UM中查看到了关于Uart模块的超时的相关功能。于是我们将“Uart Timeout Enable”的功能使能，生成配置文件后，在项目中进行编译运行。

  在项目内，我们使能了“Uart Callback Capability”选项，使用自定义的Callback函数，其中Callback的形参Event为Uart模块定义的枚举类型：

、

  同时，在该Uart频道上的数据为1Hz的发送频率，通过劳德巴赫调试，我们发现，在程序开始运行之后，程序触发事件为LINFLEXD_UART_IP_EVENT_IDLE_STATE的中断，并进入了Callback函数内。然后Uart就不再更新数据了，查看了寄存器如下:

  然后，我们又在该事件下做了相应的处理，发现当触发事件后，重新调用“Uart_AsyncReceive”函数，这样Timeout事件就是滚动触发；

  是否可以这样理解uart的超时机制：

  当Uart频道接收完一帧数据之后，如果Uart处于空闲状态，寄存器UARTCTO会逐一增加，当UARTCTO等于预设寄存器UARTPTO时，触发超时事件中断，关闭RxEn使能，Uart不会主动恢复接收状态。如果将接收后的数据处理完后，再次调用Uart_AsyncReceive函数，若Uart还是处于空闲时候，又会再次进入超时中断。

  我们期望需求：

  不知道该芯片的Uart机制是否如上我们猜测这样。如果不是请指正，便于我们更好的实现业务。我们希望的Uart的超时机制为：超时中断只做通知操作，且只在当Uart由繁忙转为空闲的时候，该种情况下会触发相关中断，不需要重复调用 Uart_AsyncReceive 函数。这样我们就能够在中断触发时候对收到的当前帧数据做处理，提供数据传递的实时性。

  希望NXP能有专家解答，谢谢！

S32G2 

[Daniel-Aguirre]

Hi,

Can you let us know which RTD version are you using? Also, is this a custom board or an NXP reference board? Are you using any NXP examples as a base?

As for the overall behavior, we might not understand it correctly. We understand the following:

• Speed of UART is 1 bps.
• You enabled the timeout feature under the LINFlexD module.

Is this correct?

As for the following comment:

"We hope that the timeout mechanism of the Uart is as follows: The timeout interrupt only notifies the Uart when it changes from busy to idle. And you don't need to call the Uart_AsyncReceive  function again. In this case, the relevant interrupt is triggered. In this way, we can process the current frame data received when the interrupt is triggered, providing real-time data transmission."

We don't understand the reason for the timeout callback. The timeout feature will trigger an interrupt, and you are looking for receiving frames in the timeout interrupt? Help us elaborate more on the application you are looking for, for us to better understand the implementation you require. 

We do apologize.

Please, let us know.

[KeithWANG]

Thank you for your attention, the following questions to clarify and confirm:

1. The version of the RTD is S32_RTD_4.4_4.0.1_D2302, and the version of the Uart module is V4.0.1, AS4.4.0.

2. The development board we use is S32G-VNP-RDB2, namely GoldVIP. Our self-developed T-Box design and development based on reference

3. The example we use is the Autosar version provided by EB, AutoCore_OS, which is modified based on this project

4. The baud rate of the UART channel is set to 460800 BPS, but the GNSS module connected to the channel sends 1bps of data. In addition, the timeout module that we enable is under the LINFlexD module, and the UART mode (UARTCR[UART] = 1) is selected.

5. “The timeout feature will trigger an interrupt, and you are looking for receiving frames in the timeout interrupt?” Basically yes, it is also based on GNSS data frames of indefinite length. We hope to receive an interrupt at the end of receiving, and then the channel will continue to receive. The interrupt can only give a Notification, just like the notification in ADC module. Of course, recently we looked at the relevant manual introduction, it seems that the use of Uart at this stage is the need to constantly call Uart_AsyncReceive related functions to enable the receive register to open the channel, so that the data is constantly rolling reception.

  Thanks! Looking forward to your reply

[Daniel-Aguirre · Accepted solution]

Hi,

Thanks for your feedback. We still have some doubts on regards of the application, since UART can only be synchronized if both interfaces are set at the same baudrate, and at this moment we understand that they are not. Again, this seems to be a misunderstanding from our side, we do apologize.

As for the overall situation, what you are mentioning under point 5 seems to be correct. If you are expecting to receive information, but you cannot wait for it, AsyncReceive is a non-blocking function which should trigger an interrupt once information is available under the respective buffers. Also, the following recommendations are shown under the S32G2 RM:

For which, if the number of bytes to be received are not always the same, the recommendation is to receive byte per byte, to trigger the respective interrupt as expected.

Please, let us know.

[KeithWANG]

Thank you for your answer. That should answer some of our questions.
The baud rate we use is the same, but the output data of the GNSS module is updated once per second, which can be understood in this way.