cancel
Showing results for 
Search instead for 
Did you mean: 

stm32n6 (stack switching problem)

Franzi.Edo
Senior

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

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

3 REPLIES 3
KnarfB
Super User

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 

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

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