Ethernet abnormality enters the common interrupt function causing MCU reset

[2360820408]

During the stability test of MCU (model S32K341), we found that the MCU restarted ab

normally. Later, we located that the last function entered before the restart was the Ethernet's common interrupt function. The specific reset point is as follows:

Through log records, we determined the values of the following two registers: DMA_Interrupt_status (0x40481008) = 0x00020000; The corresponding register description (indicates which major module of Ethernet generated the interrupt):

MA_CH0_Status (0x40481160) = 0x00000405; Corresponding register description (indicating the specific reason for the interrupt)

Background description:

We are conducting a stability test where this board communicates with other boards via large-scale Ethernet communication. The recurrence probability of this issue is once every 48 to 72 hours, and it leads to an MCU reset. We are using the MCA version as shown in the figure below. In our code, there is a continuous transmission of 10ms periodic messages, and we are utilizing the FreeRTOS operating system. Additionally, there is another task performing MDIO read and write operations every 200ms.

[lukaszadrapa]

Hi @2360820408 

Did you check what was the source of reset exactly? You can read DES and FES registers in MC_RGM. The registers are reset only on power-on reset, so you should log the content and then clear all the flags after each reset in order to have up to date information next time.

Regards,

Lukas

[2360820408]

Hi,Lukas
I may not have described it clearly before. My project has specifically identified a watchdog timeout reset. The breakpoint I mentioned earlier represents the state before entering the watchdog interrupt function. My current speculation is that my project frequently enters this common interrupt, which prevents normal feeding of the watchdog, resulting in a timeout reset.
Regards,
Jerry

[lukaszadrapa]

Well, this should be solved on application level, not sure how can I help with this...

Regards,

Lukas

[2360820408]

Hi,Lukas，
What I want to know is under what circumstances the MCU will enter the common interrupt function. During normal debugging, this interrupt cannot be triggered. For Ethernet, only the receive interrupt and send interrupt will be triggered, but after an abnormal situation occurs, it will enter this common interrupt frequently, resulting in watchdog timeout and reset.
Regards,
Jerry

[lukaszadrapa]

I did deeper research and I found ticket ARTD-47931 which describes situation when the code can stuck in GMAC_CommonIRQHandler(). It was fixed in RTD 3.0.0. I can see that you are using older version, so my recommendation is to update the RTD.

Regards,

Lukas

[2360820408]

we want to confirm whether this problem will recur, and we need to know the recurrence method, that is, the method to enter the common interrupt function.And Can you share the related descriptive document of ARTD-47931 with us?
Regards,
Jerry

[lukaszadrapa]

Well, the common interrupts were not masked by MMC_Rx_Interrupt_Mask and MMC_Tx_Interrupt_Mask registers in version 2.0.3.
In case of high traffic, the common interrupt would be triggered if counter reaches half or maximum value. This was not handled by the driver appropriately, the flags are not cleared in the handler.
In version 3.0.0, the interrupts are masked by this in init function:
/* Disable common interrupt from MMC */
Base->MMC_TX_INTERRUPT_MASK = 0x03FFFFFFU;
Base->MMC_RX_INTERRUPT_MASK = 0x03FFFFFFU;

Then the interrupts are not triggered.
It's possible that this will be updated in the future revisions (6.0.0 or higher) and the interrupts will be handled in different way. But currently it's fixed as described.

[2360820408]

Thank you very much for your answer. I would like to know if it is feasible for me to disable the common interrupt function in this version of the driver as a temporary solution.
Regards,
Jerry

[lukaszadrapa]

You can do the same in your code. This is the difference:

[2360820408]

Thank you very much for your answer.

[lukaszadrapa]

I'm checking this with SW team because it's little bit confusing. I will let you know later. Thanks for patience.