• State Verified Answer
  • Replies 1 reply
  • Subscribers 74 subscribers
  • Views 323 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 256785
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hardfault handler implementation - changing SP in case of stack overflow

Sreejit

Hello,

I currently designing fault handling for a firmware for nrf52840 in SES for SDK16.

At line number 68 in the hardfault_handler_gcc.c, assuming a stack overflow happened and we want to reset the SP pointer, shouldn't BHI (Unsigned comparison gave higher) instruction be changed to BLH (Unsigned comparison gave lower or same), as the PSP will be lower if it overflows the limit, the stack being full descending in case of cortex m4.

Regards.

Parents
  • +1

    Nope. That check in line 68 checks if the SP was bigger than  __StackTop, which is equal to end-of-RAM in most cases. That indicates something has completely trashed the SP value altogether, and it is unusable. Hence the jump to "_MoveSP", which just uses __StackTop in order to keep the remaining C code form generating another hard fault (would result in lockup reset).

    Also note that this code won't work properly with PSP (e.g. RTOS) setups, as it assumes one single stack between __StackTop and __StackLimit.

Reply
  • +1

    Nope. That check in line 68 checks if the SP was bigger than  __StackTop, which is equal to end-of-RAM in most cases. That indicates something has completely trashed the SP value altogether, and it is unusable. Hence the jump to "_MoveSP", which just uses __StackTop in order to keep the remaining C code form generating another hard fault (would result in lockup reset).

    Also note that this code won't work properly with PSP (e.g. RTOS) setups, as it assumes one single stack between __StackTop and __StackLimit.

Children
No Data
Related
Terms of service