Failure reaction in case of Stack overflow or underflow - S32K1

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Failure reaction in case of Stack overflow or underflow - S32K1

3,444 Views
steve_gähl
Contributor I

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

0 Kudos
Reply
5 Replies

3,186 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

612 Views
raj12
Contributor III
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
0 Kudos
Reply

2,454 Views
wangyang06014
Contributor I

Hi,

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

not exeuted

0 Kudos
Reply

2,372 Views
jeremie_chirat
Contributor II

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,

0 Kudos
Reply

3,186 Views
tkdwofl
Contributor III

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.

0 Kudos
Reply