2025-07-30 1:44 PM
Dear all,
I'm encountering a strange issue with the STM32N657.
I have a very simple test application that successfully turns on an LED — everything works as expected.
Now, I need to switch the stack and enable the PSP. To do so, I’m using the following code:
uint8_t PSPstack[800] __attribute__((aligned(8)));
__set_PSP((uint32_t)(PSPstack + sizeof(PSPstack)));
__set_CONTROL(__get_CONTROL() | 0x2); // Set SPSEL = 1 to use PSP
__asm volatile ("isb");
However, as soon as I execute this code — specifically the line setting CONTROL to 0x2 — the system enters an exception (likely a fault handler), and execution stops.
Do you have any idea how to debug this or what could be going wrong?
Thanks in advance for your help.
Kind regards,
Edo
Solved! Go to Solution.
2025-07-31 12:02 AM
Hi KnarfB,
Issue solved — thank you!
It turns out that the Cube bootstrap FSBL initializes the stack limit registers.
So when I tried to switch the stack, an exception was triggered.
The workaround was simple: setting those limit registers to 0 before switching the stack.
Now everything works perfectly.
Thanks again for your help.
Best regards,
Edo
2025-07-30 10:55 PM
The Cortex-M55 has Stack Limit registers, did you set them up?
Are you using HAL, SysTick (or other) interrupts?
The new stack is a local variable on the old stack, did you mean that?
More info on that exception / fault handler? Can you debug? Try Cortex-M Fault - SEGGER Knowledge Base
hth
KnarfB
2025-07-30 11:07 PM
Hi KnarfB,
Thank you for your suggestions.
I do not use any HAL nor interruptions. It is really a minimalistic bare metal test.
The stack is defined as static (outside of the routine and it is located in the bus section). Unfortunately I cannot debug with Ozone because I am waiting for a new cable adapter for the probe (in the Nucleo-N6 the connector was changed). What I can indirectly measure id that __get_IPSR() is = to 0U before my test, so, I am not in a Handler mode and I should be able to change this stack. Now, I did't touch the Stack Limit registers. Maybe I have to investigate in this direction. Maybe, in the initial FSBL boot of the Cube, has set these registers ...
Thank you,
Edo
2025-07-31 12:02 AM
Hi KnarfB,
Issue solved — thank you!
It turns out that the Cube bootstrap FSBL initializes the stack limit registers.
So when I tried to switch the stack, an exception was triggered.
The workaround was simple: setting those limit registers to 0 before switching the stack.
Now everything works perfectly.
Thanks again for your help.
Best regards,
Edo