Failure reaction in case of Stack overflow or underflow - S32K1

[steve_gähl]

Hello Community,

i could not find out which is the failure reaction of the S32K144 in case of Stack overflow or underflow. What happens with the controller when Stackpointer is not in correct address range?

Please, could someone help me?

Best regards,

Steve

[lukaszadrapa]

Hi,

first of all, be aware that there’s no stack monitor by default. Safety manual suggests that data watchpoint comparator in DWT can be used. See the section “5.6.3.1 Stack” in:

https://www.nxp.com/docs/en/reference-manual/S32K1XXSM.pdf

The reaction is application dependent. If the stack overflows or underflows, it usually means that something went wrong in the program and there’s usually no way to recover. Common reaction is to put the system to some safe state (again, this is application dependent, there’s no general guideline) and reset the device.

I can provide very simple sample codes for DWT – see please attachment (one for S32K148, second is for S32K144).

Regards,

Lukas

[raj12]

Hello @lukaszadrapa,

I am injecting the stack overflow error, and after successfully injection of error DebugMon_Handler exception triggering.

I have a query Related to recovering methods. during testing observed only After power on reset MCU is able to recover from Stack Overflow exception.

Please let me know is there any other methods of recovery.
Thanks

[wangyang06014]

Hi,

I have run the the S32K148_DWT_StackOverflow.zip sample,but the DebugMon_Handler was

not exeuted

[jeremie_chirat]

Hello @wangyang06014 ,

We tried to implement it, also for S32K148, and initially we had the same issue than you.

The problem is only in debug mode, as it seems the debugger controls the DebugMon_Handler interrupt in a particular way, because in debug mode there actually is a break when it goes in overflow (run is interrupted inside the "push" loop at loop 16) but the DebugMon_Handler code is not executed.

However in normal run without the debugger attached the code inside DebugMon_Handler is executed correctly : on the EVB with example code the LED lights up in RED as expected (and for our project we put some debug statement on uart and saw it printed as expected).

Once you have tested it, to actually implement it in your system, it seems you have to insert the actual address for your stack limit (if you leave the comparator setting as in the example, the error will be triggered after a few function calls:

Original:
DWT->NUMCOMP[0].COMP = (uint32_t)stackPointer - (16 * sizeof(uint32_t));

I set it using the actual address from the linker file:

extern uint32_t __StackLimit[];

#define DWT_OVERFLOW_DATA_ADDR ((uint32_t )(__StackLimit))

DWT->NUMCOMP[0].COMP = DWT_OVERFLOW_DATA_ADDR;

Can someone from NXP confirm that it is the correct way to implement it in a running system?

Best regards,

[tkdwofl]

S32K14x_DWT_StackOverflow_Detection.zip do not have elf file.

Desktop\S32K14x_DWT_StackOverflow_Detection\S32K14x_DWT_StackOverflow_Detection\Debug\S32K14x_DWT_StackOverflow_Detection.elf not found.