How do the SDK's HardFault_Handler()'s work?

[Elias]

I'm trying to reduce the size of my firmware update binary. It turns out that although enabling the "Execute-only Code" option in Keil increases my code size, it ends up decreasing the size of my compressed firmware update binary!

Unfortunately, to get the project to compile with the "Execute-only Code" option, I have to remove hardfault_handler_keil.c; otherwise, I get the following errors:

• hardfault_handler_keil.c(55): error: A1944E: Literal pool entries cannot be generated in execute-only sections
• hardfault_handler_keil.c(67): error: A1944E: Literal pool entries cannot be generated in execute-only sections
• hardfault_handler_keil.c(68): error: A1944E: Literal pool entries cannot be generated in execute-only sections

If I remove hardfault_handler_keil.c, then upon a HardFault, my system would use the default handler, which is just an infinite loop, instead of getting to our custom HardFault_process(), and this is not acceptable.

I have an alternative implementation of Hardfault_Handler() that does not cause compilation errors:

extern void HardFault_c_handler(uint32_t * p_stack_address);

void HardFault_Handler(void)
{
  uint32_t r0;
  __ASM volatile("   mrs r0, msp        \n");

  uint32_t *p_stack = (uint32_t*)(void*)(r0);

  HardFault_c_handler(p_stack);
}

But this is seems "too easy". Can I get a description of the general "purpose" of the HardFault_Handler() function in hardfault_handler_keil.c? Would my implementation not handle certain types of HardFault? I'm not well-versed in ARM assembly, so I'm not all that sure what it's intended to do.

I am using the nRF52832 and nRF5 SDK v17.1.0.

[Susheel Nuguru]

At line 55, 67 and 68 you can see that the implementation uses literal values that cannot be placed in Execute only section. So your implementation which does not use literal entries seems to be a decent workaround for this.

[Elias]

Does my implementation have any drawbacks that I'm not aware of? Why didn't Nordic just come up with my implementation on their own, given that it's much simpler, and has at least one clear advantage?

[Susheel Nuguru]

There seems to be a bit extra handling in hardfault_handler_keil.c where the MSP is compared to be within the stack bounds. You do not seem to be having that. Apart from that there is no disadvantages that I can see. Having SP reset to max stack limit when the MSP crosses over the stack area seems like just error handling, but I am unsure what advantage it gives.

[Elias]

Ah! Yes, doing a bounds-check on the stack pointer makes sense. You wouldn't want to try to de-reference a corrupt stack pointer.