S32K358 eMIOS ISR stuck at 85°C

[simon98]

Dear NXP Support Team,

we are facing an issue on S32K358 during temperature tests at around 85°C.

In our application we use 6 eMIOS channels, each one configured to generate interrupts on both PWM edges with a frequency of 200Hz.

At 85°C, the MCU sometimes gets stuck inside one eMIOS ISR. The ISR does not exit because the code checks the interrupt flag by reading the eMIOS registers, but the flag is 0 (file Emios_Mcl_Ip_Irq.c

if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) 

After debugging, we noticed that when the issue occurs, the variable containing the eMIOS base address is NULL (Emios_Ip_paxBase). When the application works correctly, the same pointer is valid and the eMIOS registers are read properly.

It seems that, in some conditions, the reference to the eMIOS peripheral is corrupted or cleared during ISR execution.

Do you have any indication about possible known issues or root causes, such as stack overflow, memory corruption, concurrent accesses, ISR handling, or temperature-related behavior?

Best regards,

Simon

[VaneB]

Hi @simon98 

Which RTD version are you working with? Any additional information would be helpful.

Also, in RTD versions prior to 6.0.0, there was a known issue related to the incorrect memory mapping of static variables within function scope (ARTD-159985).

This issue describes a problem where the variable Emios_Ip_paxBase, defined in both Emios_Mcl_Ip.c and Emios_Mcl_Ip_Irq.c, is assigned inconsistent initialization characteristics. Further details are provided in the Software Release Notes.

BR, VaneB

[simon98]

Hi vane,
I'm currently using RTD 7.0.0

[VaneB]

Hi @simon98 

Could you please provide a simple application that reproduces the observed behavior? Also, could you confirm whether you are working with a custom board or an evaluation board?

Additionally, could you share how the testing is being performed to confirm that the issue occurs at 85 °C?

[simon98]

Hi @VaneB ,

Currently i'm working with a custom board with S32K358 where i use these eMIOS_1 channels to generate PWM of 200 Hz: ch3, ch9,  ch11, ch12, ch13, ch19. Code is generated using SImulink 

Putting my custom board into a climatic cell at 85°C i've observed the stucking behaviour after some time.

While i was debugging with S32DS (3.6.7) I've found out that it stuck into the ISR(EMIOS1_1_IRQ) so i've put into it some custom counter near entry/exit function, and also into Emios_Pwm_IrqHandler and Emios_Pwm_Ip_IrqHandler functions, in order to detect what parts of the code are executed. 

After some tests i've found out that, when it stucks, inside

static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel)
{
    /* Check that an event occurred on Emios channel */
    if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))
    {
        /* Check that an event occurred on EMIOS channel */
        if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))
        {
            Emios_Pwm_Ip_IrqHandler(Instance, Channel);
        }
        else
        {
            /* Do nothing - in case of spurious interrupts, return immediately */
        }
    }
}
 
the if condition:

if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))
 
is always 0 because, for some reason, Emios_Ip_paxBase[Instance] points to 0. This means that nobody is clearing the interrupt flag so it enters in a loop where it cannot escape.
 
here's the code i've used to detect this probelm:

static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel)
{
    // uint32_t s;
    // uint32_t c;
    // uint32_t s_flag;
    // uint32_t s_ovr;

    dbg_pwm_last_instance = Instance;
    dbg_pwm_last_channel = Channel;

    dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance];
    dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;
    dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;
   
    dbg_emiosipirq_static_state1++;

    /* if (Instance == 1)
    {
        switch (Channel)
        {
            case 16:
                dbg_emiosipirq_static_cnt_ch16++;
                break;

            case 17:
                dbg_emiosipirq_static_cnt_ch17++;
                break;

            case 18:
                dbg_emiosipirq_static_cnt_ch18++;
                break;

            case 19:
                dbg_emiosipirq_static_cnt_ch19++;
                break;

            default:
                dbg_emiosipirq_static_cnt_oth1++;
                break;
        }
    }
    else
    {
        dbg_emiosipirq_static_cnt_oth2++;
    } */

    /* Lettura reale dei registri vista dal codice */
   /*  s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;
    c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;

    s_flag = s & (uint32)eMIOS_S_FLAG_MASK;
    s_ovr  = s & (uint32)eMIOS_S_OVR_MASK;

    dbg_pwm_last_s = s;
    dbg_pwm_last_c = c;

    dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK;
    dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK;

    dbg_pwm_last_s_and_flag = s_flag;
    dbg_pwm_last_s_and_ovr = s_ovr;

    if (s_flag != 0U)
    {
        dbg_pwm_s_flag_yes++;
    }
    else
    {
        dbg_pwm_s_flag_no++;
    }

    if (s_ovr != 0U)
    {
        dbg_pwm_s_ovr_yes++;
    }
    else
    {
        dbg_pwm_s_ovr_no++;
    }

    if ((s_flag == 0U) && (s_ovr != 0U))
    {
        dbg_pwm_flag0_ovr1_count++;
    }
    else if ((s_flag != 0U) && (s_ovr != 0U))
    {
        dbg_pwm_flag1_ovr1_count++;
    }
    else if ((s_flag != 0U) && (s_ovr == 0U))
    {
        dbg_pwm_flag1_ovr0_count++;
    }
    else
    {
        dbg_pwm_flag0_ovr0_count++;
    } */

    /* Check that an event occurred on EMIOS channel */
    if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))
    {
        dbg_emiosipirq_static_state2++;

        /* Check that an event occurred on EMIOS channel */
        if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))
        {
            dbg_emiosipirq_static_state3++;
            Emios_Pwm_Ip_IrqHandler(Instance, Channel);
        }
        else
        {
            dbg_emiosipirq_static_state4++;
            /* Do nothing - in case of spurious interrupts, return immediately */
        }
    }
    else
    {
        dbg_emiosipirq_static_state5++;
        //Emios_Pwm_Ip_IrqHandler(Instance, Channel);
        //Emios_Pwm_Ip_IrqHandler(1, 19);
    }
}

These are the global vars in which i've stored the addresses which Emios_Ip_paxBase should point to:

dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance];
dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;
dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;

I've put also some custom code to read NVIC registers run time: attached you can find the file with Thread, general registers, NVIC registers and variables expressions, EMIOS registers, for 6 tests i made.

Also i will provide you the S32DS project i used to test this behaviour in a private message.

I hope all these information could be usefull. I remain at your disposal for any further information.

BR,
SImon

[VaneB]

Hi @simon98 

Thank you very much for providing this information.

Since the code appears to be getting stuck in EMIOS1_1_IRQ, which corresponds to eMIOS 1 Channel 19 based on your configuration, let’s try to narrow the analysis to this specific part.

To simplify the debugging and rule out any interference from other modules, please create a minimal test project that only includes this eMIOS configuration. This will help us isolate the behavior and better understand the root cause. For guidance, you can review the examples provided in the thread S32M27x/S32K3 – eMIOS Usage.

Does the same behavior still occur? Also, if you have an evaluation board, it would be great if you could try the same code there.

[simon98]

Hi @VaneB ,

I tested the issue on my custom board using a simplified configuration that only includes the six eMIOS1 channels. Unfortunately, in this setup I am not able to reproduce the error. The application runs correctly and does not get stuck in EMIOS_1_IRQ.

At the moment, I am looking into whether it is feasible to load the complete project developed for our custom board onto the EVB. Before proceeding, I would also like to understand if the hardware differences between the custom board and the EVB could potentially lead to any unexpected behavior or even damage to the EVB.

BR,
Simon

[VaneB]

Hi @simon98 

Our evaluation boards are designed mainly for use at room temperature and have not been tested or qualified for very low or very high temperatures.

You may still use the evaluation boards outside the room-temperature range, but we cannot guarantee their performance under those conditions.

[simon98]

Hi @VaneB ,

After several attempts, I managed to create an EVB project that reproduces the application running on my custom board as closely as possible. In particular, I configured all the pins in the same way as in my custom project.

I then tested this project on my custom board under 85°C conditions, and the eMIOS ISR issue still occurred: the application continued to get stuck.

After that, I tested exactly the same project on the EVB under the same temperature conditions and over (90°C), but I was not able to reproduce the issue—the EVB continued to operate correctly without getting stuck.

At this point, what would you recommend as the next steps to identify the root cause of the problem and find a possible solution?

Please let me know if you need any additional information, measurements, or debugging data from my side.

I have attached a ZIP file containing the complete EVB project and the pictures of the K358 on my custom board and on the EVB.

Thank you for your support.

BR
Simone

[VaneB]

Hi @simon98 

As the issue is observed on your custom board but not on the EVB, it would be worthwhile to investigate whether the root cause could be hardware-related.

I recommend comparing your hardware design against the EVB schematic and reviewing the S32K3 Hardware Design Guideline to verify that all relevant recommendations have been properly implemented.

[simon98]

Hi @VaneB 

I would like to gently follow up on this topic, as we are still investigating the issue on our side and would appreciate your feedback.

In particular, if the root cause were related to RAM corruption (for example, an out-of-bounds write or stack overwrite), which registers or diagnostic information would you recommend checking on the S32K358?

Are there any specific fault status registers, ECC/error reporting registers, MPU-related registers, stack monitoring features, or other debug registers that could help identify whether memory corruption has occurred before the eMIOS ISR gets stuck?

Any guidance on the most useful registers to inspect during debugging would be greatly appreciated.

Thank you for your support.

Best regards,

Simon

[VaneB]

Hi @simon98 

Since this appears to be a hardware-related issue specific to your board and we can not reproduce it, it is difficult to accurately diagnose the root cause through this support channel. We recommend contacting your distributor or local NXP representative for further assistance,

[simon98]

Hi @VaneB,

the HW design has been reviewed on our side and no evident hardware issue has been found. Also, the board is not directly comparable with the NXP EVB due to different hardware design and operating conditions.

If a customer observes temperature-related issues on a custom board, how could it be possible to obtain one-to-one support from NXP?

BR,

Simon

[simon98]

Hi vane,
I'll try this week to give you a simple project that replicate the behaviour