I'm trying to investigate a HardFault that happens within half an hour of using our product.
Device is nRF52832, SDK is 17.1.0, SD is S132 7.2.0
So far, I never managed to have the issue trigger while debugging with SES/Ozone. It does happen, however, with the J-Link physically attached, so I was able to attach SES/Ozone and inspect the program status after it happened (program loops in HardFault_Handler).
It seems to consistently crash in the same state (looking at the data pushed into the stack):
R0=00000004
R1=10000000
R2=00026000
R3=0002653F
R4=200000B8
R5=00000000
R6=E000E000
R7=00000062
R8=00000002
R9=200053F0
R10=00000000
R11=00000000
R12=20003424
R13(SP)=2000FE88
R14(LR)=FFFFFFE9
R15(PC)=0002635E
PSR=21000003 (nzCvqT)
HFSR=40000000 = FORCED
UFSR= 0000 = /
BFAR= 01 = IBUSERR
MMFAR= 00 = /
VTOR=00000000
Memory at SP (0x2000FE88):
00025278 2000FEF0 E000E100 20005833 20003424 00016299 10000000 61000000
As far as I understand, this indicates that the CPU tried to jump to 0x10000000 and the LR was 0x16299, which is in the SoftDevice region.
The problem is, I don't understand what could make the CPU jump to such an address. The assembly code around 0x16299 doesn't seem to do anything like that.
I believe the hardfault happens while running the function at 0x25268, the value of saved registers in the stack seem to confirm that, but in practice that function seems to only do a WFE.
The only explanation I could think of is that the CPU would read 0x10000000 from the Vector table and try to jump to it, but VTOR points to the MBR and its values seem legit.
How can I further investigate this?
