topic S32K3MCU SENT slow channel Cannot receive data. in S32K

S32K3MCU SENT slow channel Cannot receive data.

khty — Tue, 30 Jun 2026 02:39:12 GMT

Hello everyone

I am using the SENT interface of the S32K311 to receive data, and I have encountered a situation where the fast channel receives data normally, but the slow channel is unable to receive any data.

And I monitor the SENT error notification function, there are no exceptions.

The MCU is S32K311

RTD version :S32DS 3.6.2 RTD6.0.0

SENT Sensor: Sensata Pressure Sensor Enhanced Slow message

Firstly, I know that the SENT logic is processed in the "Flexio_Sent_Ip_ProcessSerialMsg" function, and subsequently, in the outer layer function, it monitors the "Data->SerialState" and "FastMsgCount" variables to determine if the slow channel has completed receiving data.

So, I captured the relevant bit information.

bit(x) : SENT Fast Channel Status Nibble bit

S : "STATUS_SENT_SERIAL_SHORT".

E : "STATUS_SENT_SERIAL_ENHANCED"

I discovered that the parsing logic for the slow channel is repeatedly jumping and cannot be parsed normally.

Does the processing logic of SENT have any errors when in a certain situation?

thanks

Re: S32K3MCU SENT slow channel Cannot receive data.

Julián_AragónM — Sat, 04 Jul 2026 00:03:57 GMT

Hello @khty,

Could you share the Sensata sensor's sent configuration? From your images, I can see bit C in position 8 is set as 0; I assume 8-bit message ID, 12-bit data format is being used.

Since your fast channel is received correctly and no SENT error notification is reported, I understand the issue is related to the processing function.

I've not been able to find any known issues regarding slow channel reception; however, I've triggered a discussion with the internal team, let me try and get further information regarding this issue.

Finally, are you able to provide a full capture of at least 18 consecutive SENT frames? This way we can further check whether the RTD state machine behavior matches the expected enhanced serial decoding sequence.

Best regards,
Julián

Re: S32K3MCU SENT slow channel Cannot receive data.

khty — Sat, 04 Jul 2026 09:02:35 GMT

hello，and thank you for your quick response to my question.

The sensor configuration information provided by Sensata is shown in the following figure:

For your last request, a full capture of at least 18 consecutive SENT frames.I have provided it in the "bitChange.xlsx" file in the appendix.

I have displayed the second and third bits of each captured status half-word in the table.

In the table, each column represents a SENT message. Each large black square frame encompasses one slowChannel message. The blue area is the ID region, the green area is the CRC region, and the yellow area is the data region.And the information at the bottom is the result of manual analysis.

If you need any additional information, please let me know, and I will respond as soon as possible.

Re: S32K3MCU SENT slow channel Cannot receive data.

db16122 — Sat, 04 Jul 2026 09:07:34 GMT

any error log from SOC side？

Re: S32K3MCU SENT slow channel Cannot receive data.

khty — Mon, 06 Jul 2026 01:33:57 GMT

The FAST Error Notification and SLOW Error Notification of SENT have reported no faults.

You can read the data recorded in "bitchange.xlsx" for analysis, as it contains information on the 2 and 3 bits of each status half-word of the fast channel that I have recorded. Bit1 and Bit0 information are discarded because they have no meaning in the slow channel.

At the same time, I have manually parsed the slow channel information and identified it with black squares.

In "bitchange.xlsx", the data in the "State" row corresponds to "Flexio_Sent_Ip_axFastData[Instance][ChannelId].SerialState" in the code. This is responsible for detecting and identifying whether the slow channel is "Short" or "Enhanced". The "count" represents "Flexio_Sent_Ip_axFastData[Instance][ChannelId].FastMsgCount", which is responsible for counting the receive length of the slow channel.

I believe the reason we are not receiving any Slow Channel data is that the code cannot correctly identify whether the slow channel is "Short" or "Enhanced". You can read "bitchange.xlsx" to discover that the identification state is constantly jumping between "STATUS_SENT_SERIAL_IDLE", "STATUS_SENT_SERIAL_SHORT", and "STATUS_SENT_SERIAL_ENHANCED".

When the identification state transitions, the "Flexio_Sent_Ip_ProcessSerialMsg()" function returns "STATUS_FLEXIO_SENT_IP_ERROR", but this return value is only resetting SerialState and FastMsgCount in the upper-level function "Flexio_Sent_Ip_DmaDataProcessing()", and it does not call SentFastErrorNotif(). Therefore, I cannot obtain any error information through the fast Error Notification.

In “bitChange.xlsx”

We can start from column T, at this time SerialState = STATUS_SENT_SERIAL_IDLE, FastMsgCount = 0.
When we receive column U, Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 1, so it considers this a start signal for slow channel and sets SerialState = STATUS_SENT_SERIAL_SHORT and FastMsgCount = 1.
When we receive column V,Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 0, so it keeps SerialState = STATUS_SENT_SERIAL_SHORT and increments FastMsgCount = 2.
When we receive column W, Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 1. At this point, since FastMsgCount == 2, it does not meet the condition to jump to STATUS_SENT_SERIAL_ENHANCED, and can only return STATUS_FLEXIO_SENT_IP_ERROR. In Flexio_Sent_Ip_DmaDataProcessing(), it resets SerialState and FastMsgCount.

By the way, I am using DMA to receive SENT data, and I have only confirmed that there is an issue with the DMA reception method. At present, I cannot confirm whether the interrupt and polling methods also have the same problem.

Re: S32K3MCU SENT slow channel Cannot receive data.

Julián_AragónM — Wed, 08 Jul 2026 15:32:41 GMT

Hi @khty,

Thank you for the additional information. This makes it clearer.

This does seem to point to a potential RTD issue for parsing enhanced slow messages, however, since I lack the specific HW setup, I have not been able to reproduce the issue.

I've forwarded this information to the internal team, and I will keep you updated on any new information.

Best regards,
Julián