Hardfault without debugger - simple toggle IO program

RE: Hardfault without debugger - simple toggle IO program

SParker — Wed, 09 Aug 2017 00:35:00 GMT

I copied my program into the evaluation version of Keil and it just worked. I might try another GCC version at a later date.

RE: Hardfault without debugger - simple toggle IO program

RK — Tue, 08 Aug 2017 04:38:03 GMT

so why is the memory at 0x20000000 + 328 zero-filled when you're using the debugger but not later? There should be a piece of code in crt0 which zero-fills the .bss segment. If you hit the reset handler and it's already zero-filled, then the debugger is doing it (check by setting it to something and re-debugging).

RE: Hardfault without debugger - simple toggle IO program

SParker — Tue, 08 Aug 2017 04:26:17 GMT

00000544: ldr r3, [pc, #164] ; (0x5ec <__register_exitproc+188>) Load from 0x5ec into r3 => r3 = 0xd24 00000546: ldr r4, [r3, #0] Load from 0xd24 into r4 => r4 = 0x2000000 00000548: ldr.w r3, [r4, #328] ; 0x148 Load from 0x2000000+328 into r3 => r3 = 0 0000054c: cmp r3, #0 Compare is true 0000054e: beq.n 0x5ce <__register_exitproc+158> Take branch which populates r3 with 0x2000014c

RE: Hardfault without debugger - simple toggle IO program

RK — Tue, 08 Aug 2017 04:02:58 GMT

I'm pretty out of new ideas here. I assume those 'correct' values are loaded via that sequence I detailed above, load from 0x5ec, add 328, load from there. I can't at this point suggest why the debugger or lack thereof makes a difference. Guess you have to go all the way back to the reset_handler, set the locations to something invalid, find what writes them (with memory access breakpoints).

RE: Hardfault without debugger - simple toggle IO program

SParker — Tue, 08 Aug 2017 03:59:29 GMT

Using the debugger when it gets to

00000550:   ldr     r2, [r3, #4]

r0 = 536872028 = 0x2000 045C, r3 = 536871244 = 0x2000 014C

These are valid areas in RAM. Without the debugger r0 and r3 become invalid.

RE: Hardfault without debugger - simple toggle IO program

RK — Tue, 08 Aug 2017 02:46:19 GMT

well go stick a breakpoint there and see what happens when you DO run under the debugger, perhaps that will hint what's going on. If it were a different debugger (like Segger Embedded or something) I'd suggest that perhaps it wasn't going from the reset handler and was doing something odd, but I'm reasonably sure gdb via gdbserver is pretty plain vanilla.

RE: Hardfault without debugger - simple toggle IO program

SParker — Tue, 08 Aug 2017 01:46:13 GMT

Yeah, thanks for taking a look! I might have to compare my compiler stuff with different example code. It's gotta be something... FYI 0x02AE is inside _start as a call to __libc_init_array

I've also tried changing to newlib-nano and have exactly the same symptoms and still crashes inside __libc_init_array.

RE: Hardfault without debugger - simple toggle IO program

RK — Tue, 08 Aug 2017 01:14:48 GMT

ok there's more to it then. Firstly I was wrong, hardfault is a precise fault so 0x0550 is the instruction which was executing (not the return-to address). So you were doing ldr r2, [r3,#4]. No shock that faulted, r3 is 0xbb7dfffb which is rubbish.

So r3 was loaded with (I think) 0x5ec. , r4 was loaded from that address, r3 was loaded from r4 + 328 and that was probably 0xbb7dfffb and that's not zero so the branch wasn't taken and then you HF at 0x0550 trying to load from that address + 4.

At this point, that's all I can tell.

RE: Hardfault without debugger - simple toggle IO program

SParker — Tue, 08 Aug 2017 00:58:30 GMT

The code around here is c library code:

          __register_exitproc:
00000530:   stmdb   sp!, {r3, r4, r5, r6, r7, r8, r9, lr}
00000534:   ldr     r5, [pc, #176]  ; (0x5e8 <__register_exitproc+184>)
00000536:   mov     r6, r0
00000538:   ldr     r0, [r5, #0]
0000053a:   mov     r8, r3
0000053c:   mov     r7, r1
0000053e:   mov     r9, r2
00000540:   bl      0x528 <__retarget_lock_acquire_recursive>
00000544:   ldr     r3, [pc, #164]  ; (0x5ec <__register_exitproc+188>)
00000546:   ldr     r4, [r3, #0]
00000548:   ldr.w   r3, [r4, #328]  ; 0x148
0000054c:   cmp     r3, #0
0000054e:   beq.n   0x5ce <__register_exitproc+158>
00000550:   ldr     r2, [r3, #4]
00000552:   cmp     r2, #31
00000554:   bgt.n   0x590 <__register_exitproc+96>
00000556:   add.w   lr, r2, #1
0000055a:   cbz     r6, 0x57a <__register_exitproc+74>
0000055c:   add.w   r1, r3, r2, lsl #2
00000560:   movs    r4, #1
00000562:   str.w   r9, [r1, #136]  ; 0x88
00000566:   ldr.w   r0, [r3, #392]  ; 0x188
0000056a:   lsls    r4, r2
0000056c:   orrs    r0, r4
0000056e:   cmp     r6, #2
00000570:   str.w   r0, [r3, #392]  ; 0x188
00000574:   str.w   r8, [r1, #264]  ; 0x108
00000578:   beq.n   0x5c2 <__register_exitproc+146>

The application ends at 0x0D32, above that is blank flash.

RE: Hardfault without debugger - simple toggle IO program

RK — Tue, 08 Aug 2017 00:20:25 GMT

let's see what we can pick out of here. An exception was taken and stacked. R0, R1, R2, R3, R12 are unchanged from their stacked values, expected, the HF handler does nothing. LR is 0xFFFFFFF9 which is a standard return from exception. The stack has the return to PC and also the LR at the time of the exception. PC is 0x0550, LR was 0x0545. So likely scenario is a branch to a routine which returned to 0x5045 (0x5044 really as that odd bit just denotes thumb), then ran to the instruction before 0x0550 (probably 0x054E) and then hardfaulted.

So what code's around 0x0540 onwards for 16 or so bytes.

RE: Hardfault without debugger - simple toggle IO program

RK — Mon, 07 Aug 2017 23:28:02 GMT

no _0xFFFFFFF9 is just an exception return marker - nothing wrong with that at all. I'll have a look at the rest later.

RE: Hardfault without debugger - simple toggle IO program

SParker — Mon, 07 Aug 2017 23:23:16 GMT

Here are the CPU registers during the fault, the stack pointer looks OK to me. Trying to execute something at 0xFFFFFFFF9 looks bad though!

r0	4063042862	
r1	1269	
r2	0	
r3	3145596923	
r4	536870912	
r5	536871976	
r6	0	
r7	1269	
r8	0	
r9	0	
r10	536870912	
r11	0	
r12	0	
sp	0x2000ffc0	
lr	4294967289	
pc	0x61e <HardFault_Handler>	
xpsr	2701131779	
msp	536936384	
psp	0	
primask	0	
basepri	0	
faultmask	0	
control	0	
fpscr	0

RE: Hardfault without debugger - simple toggle IO program

RK — Mon, 07 Aug 2017 21:15:16 GMT

Can we get a register dump after you get to hardfault? Knowing where the SP is would be helpful for one. That stack trace looks as if the first call (ie first branch link) has stacked the return address, done the work and then returned to nowhere and faulted. The most likely cause of that is a stack pointer not initialised correctly on startup without the debugger.

RE: Hardfault without debugger - simple toggle IO program

Turbo J — Mon, 07 Aug 2017 12:58:48 GMT

Show us the blinky_gcc_nrf52.ld file.