stack guard module raises Hard Fault not MMU Fault

RE: stack guard module raises Hard Fault not MMU Fault

danmcb — Fri, 05 Aug 2022 07:31:43 GMT

for us it was more about understanding what was going on. We can either write the handler in asm, use the compile switch you suggested, or use the hard fault handler. Appreciate your assistance.

RE: stack guard module raises Hard Fault not MMU Fault

Vidar Berg — Thu, 04 Aug 2022 11:25:18 GMT

Fair enough. I saw this as more of a problem with how the fault handling was implemented. It seems to me like it would have been easier to just use the SDK provided hardfault handler, or is there a specific need that requires you to enable the MemManage handler?

[quote user="danmcb"]and the stack checking it does seems to be to do with which stack is in use when the fault occurs, which is not an issue here.[/quote]

That too. And in addition, if MSP is used, it will check if it is within the allocated stack section. If it isn't, then the SP will be reset back to its initial value.

RE: stack guard module raises Hard Fault not MMU Fault

danmcb — Thu, 04 Aug 2022 10:59:26 GMT

the whole thing is about the stack guard module. In fact it is working as advertised, just that there are a few subtleties about making it work well when you have a real stack overflow. Didn't know about that gcc flag, thanks, we will try it. not sure where the hard fault library comes into it, I am not using it in this example, and the stack checking it does seems to be to do with which stack is in use when the fault occurs, which is not an issue here.

RE: stack guard module raises Hard Fault not MMU Fault

Vidar Berg — Thu, 04 Aug 2022 09:51:57 GMT

OK, I see the problem now. Unlike my FW built with Segger embedded studio, yours is pushing the frame pointer onto the stack when it enters the exception handler and therefore causing another write to the MPU protected stack region. You can build your app with -fomit-frame-pointer to avoid this.

[quote user="danmcb"]WHat this means is that really the stacj guard module doesn't actually do what it should, at least if you implement the handler in C.[/quote]

Sorry, but I'm not sure I understand what this has to do with the stack guard module. We already have HardFault handling library which includes stack checking and parsing of MPU related faults.

RE: stack guard module raises Hard Fault not MMU Fault

danmcb — Thu, 04 Aug 2022 07:14:15 GMT

I did indeed put a breakpoint in Memory Management Handler, it doesn't get there. It goes straight to hard fault. But that could be something to do with the way the debugger is working I guess.

If I obj dump the handler it is like this:

00026302 <MemoryManagement_Handler>:
   26302:   b480         push   {r7}
   26304:   af00         add   r7, sp, #0
   26306:   e7fe         b.n   26306 <MemoryManagement_Handler+0x4>

So it tries to push on the stack - which is likely what causes the hard fault.

WHat this means is that really the stacj guard module doesn't actually do what it should, at least if you implement the handler in C. There are two ways to work around this:

implement the handler in assembler.
check the stack pointer in the hard fault handler, where you might want to turn off stack guard in order to be able to take corrective actions.

RE: stack guard module raises Hard Fault not MMU Fault

Vidar Berg — Wed, 03 Aug 2022 10:40:12 GMT

Hello,

I did not manage to replicate this with the code you posted. Here is the stack trace I got using your code:

And the register readout (SP is at the very beginning of my stack guard block):

The only explanation I can think of is that the memory access violation must repeated again when you enter the MemoryManagement_Handler() as this would cause the CPU to raise a hardfault exception and preempt your memory fault handler (). You may place a breakpoint in MemoryManagement_Handler() to confirm this.

I expect you would get the same issue with the trigger_stack_guard() call if you updated your stack pointer inside it:

void trigger_stack_guard(void)
{
  /* Simulate stack overflow by setting the SP to point to the guard block */
  __set_MSP(<stack guard start address >); // e.g.  __set_MSP(0x2000e400);
  static uint32_t * stack = (uint32_t *)0x2000E1FE;
  *stack = 0xDEADBEEF;
}

Best regards,

Vidar