This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Hardfault occurs when sd_flash_write returns

Hello,

I have an issue with the function sd_flash_write which ends up in a hardfault when returning to the function calling it. I know there are many Q/A on hardfaults with this function, but I'm posting a new one because none of the answers helped me and I feel that this one has a different reason. 

First of all, here are the parameters provided to sd_flash_write:

We can see that everything is aligned and we don't try to write more than one page at a time. 

Then, here is the message provided by the SDK hardfault handler:

<error> hardfault: HARD FAULT at 0x0006A98E
<error> hardfault:   R0:  0x000E5AA0  R1:  0x20028088  R2:  0x00000005  R3:  0x00000208
<error> hardfault:   R12: 0x00000000  LR:  0x0006AA67  PSR: 0x01000000

Here is a more complete dump of the fault registers:

<error> SCB->HFSR: 0x40000000 => DEBUGEVT: 0 FORCED: 1 VECTBL: 0
<error> SCB->CFSR: 0x00000000 => MMFSR: 0x00000000 BFSR: 0x00000000 UFSR: 0x00000000
<error> MMFSR => MMARVALID: 0 MLSPERR: 0 MSTKERR:0 MUNSTKERR: 0 DACCVIOL: 0 IACCVIOL: 0
<error> BFSR => BFARVALID: 0 LSPERR: 0 STKERR: 0 UNSTKERR: 0
<error>         IMPRECISERR: 0 PRECISERR: 0 IBUSERR: 0
<error> UFSR => DIVBYZERO: 0 UNALIGNED: 0 NOCP: 0 INVPC: 0 INVSTATE: 0 UNDEFINSTR: 0
<error> SCB->MMFAR: 0xE000ED34 SCB->BFAR: 0xE000ED38
<error> SCB->AFSR: 0x00000000 SCB->BFAR: 0xE000ED38

Here we can see that the fault reason is not detected, but we see that the address was 0x0006A98E. This is the address of the return instruction of sd_flash_write, as we can see from my debugging disassembly windows:

So it should jump to LR. As indicated by the hardfault message (and confirmed with the register view of my debugger), LR contains 0x0006AA67. This is the address of the instruction coming after the call to sd_flash_write, as we can see below (Note the odd address due to the fact that the next instruction, cbz, is Thumb 16 bit):

At this point nothing strikes me as being unusual or faulty, the assembly looks correct and the registers as well. A look at all the registers in the System Control Block did not show any issue. All the possible error flags mentioned in ARM Cortex M4 Generic User Guide were checked and are at zero, except for the HFSR.FORCED bit which is at 1. 

I also tried to add handlers for other fault types (Bus fault, Usage fault, MemoryManagement) with traces and breakpoint, but I never reached them, so it seems it's plainly a hardfault.

So at this point, I have no idea what this hardfault is about. The code around it doesn't seem faulty, and I can't get any useful information from the system control block indicating me why something would fail. 

Can anyone help me with this ? Whether by pointing on something I missed in the data I provided, or by giving me new leads or registers to check ? 

Context: nRF52840 (NRF_FICR->INFO.VARIANT = 0x41414330) with softdevice 6.0.0 (same issue with SD 6.1.1) built with gcc 7.2.1 (-Os). Running with a proprietary RTOS. 

Parents Reply Children
No Data
Related