Hardfault Handler is not executing for an over configured RAM size

[Akhil Francis]

I am working on nrf52810. I raised the RAM size in the linker file, which is larger than the real physical RAM capacity, for the testing purposes.
I anticipate a hard fault where the stack top will always be outside of the real physical ram. For each reset, I noticed that it would reach the reset handler, while
moving on to the SystemInit, I noticed that there was an expected hard fault exception in the IAR IDE. However, I verified by adding break points that it was not actually entering
the hard fault handler. Could you please help me with this?

[Turbo J]

Are you using softdevice? If so, you might get a lockup in the softdevice fault handler before it can call your app fault handler.

You also have to put the breakpoint at the opening "{" of the hard fault handler function, since the first line is usualy after the register setup that pushes registers on the stack.

You can use the disassembly view of the hard fault handler to put a breakpoint at the very first instruction (should be a push in most cases), which should be the only possible hit since it will lock up here.

[Akhil Francis]

Yes, I had previously tried the break point at the very first instruction of the Hardfault Handler disassembly. However, I believe your statement about softdevice is valid.

 

Observations.

1. I can see that void HardFault Handler(void) is hitting as expected when I provide the correct RAM end and RAM start, which are fit into the actual physical RAM size but specified stack and heap tiny values with ble initialization.
2. I foresee a hard fault where the stack top will always be outside of the real physical RAM if I raise the RAM end, which is larger than the real physical RAM capacity. The reset handler would be reached for each reset, and as it proceeded to the SystemInit, I saw an expected hard fault error in the IAR IDE. By adding break points, I was able to validate that it was not actually entering void HardFault Handler(void) of the application, therefore I assume it remains in softdevice HardFault Handler. In this instance, void HardFault Handler(void) was run from the application interrupt vector table after I removed the softdevice and loaded the application into the start of the flash, which is an expected one.

Here my questions are, for the first point the HardFault_Handler, is picked from the application interrupt vector table when there is a softdevice, and for the second point I guess the hard fault handler is not picked from the interrupt vector table of application instead its picked from the soft device interrupt vector table why? I am guessing normally during this transition, you will take care about the Vector Table Offset Register (VTOR) in the softdevice, But I would like to know In the point number 2, is there any chance to corrupt the VTOR wrtting from the softdevice? Or is it something else? And when I removed the softdevice, Its picked from the application Interrupt vector table, which is an expected one.

[Turbo J]

Vector forwarding is active for all interrups and exceptions. Thus everything goes Softdevice->Application, mainly because there is some very timing sensitive stuff in softdevice.

The Hardfault handler in Softdevice is not simple  - you could look into the disassembly yourself. It accesses SP-relative data, which fails and causes a lockup (-reset).

[Akhil Francis]

Okay, I understand what you're saying. Is the hard fault of the soft device not a stackless function? If not, there isn't a fix for this, am I correct?

[ovrebekk]

Hi 

I believe the SoftDevice hard fault handler will push some data to the stack, in order to provide more debug information in the hard fault handler (such as the program counter of the code that originally triggered the hard fault). 

In your case there will be a hard fault caused by trying to access the stack after reset, and then the subsequent stack access in the SD hard fault handler will lead to a CPU lock up. 

Akhil Francis said:

If not, there isn't a fix for this, am I correct?

Not really, other than making sure the RAM size configuration is correct. 

Best regards
Torbjørn

[Akhil Francis]

That is reasonable, I appreciate your response.

[ovrebekk]

Glad I could help out Akhil. The best of luck with your project