Search code examples
eclipsearmsegger-jlink

Eclipse MCU J-Link Debugger Crash on ldrb r3, [r7, #8]. Addresses are valid - [Edit - Hardware Issue]


[Edit] This turned out to be a hardware issue. A separate thread was turning on a radio power amplifier, & my Power supply current limit was tripping. The other thread was always activating exactly when this instruction was executing]

I'm struggling with this crash when debugging my project.

The CPU is SAM4LS8 (Cortex-M4). I'm using Eclipse MCU 2018/09 Debugging with SEGGER J-Link debugger. Using FreeRTOS 8.2.1 and Atemel ASF.

I have a particular instruction that crashes the debugger when I single-step over it. I'm confident the instruction and addresses are correct, so I don't think that it is the instruction itself that is the problem.

If this problem looks familiar to you, I'd appreciate your input. It's killing me.

ldrb r3,[r7,#8]

r7 Has the value 20004490 (which is the same value as in lr). The variable being accessed is a automatic variable, and the debugger successfully retrieves the value of that variable from address 0x20004498 as expected. When I try to single step through the instrcution, i get the following on the debugger console. It appears that the single-step doesn't halt correctly. (I've included the output where the debugger successfully reads the variable value before the step).

Read 1 bytes @ address 0x20004498 (Data = 0x00)
Setting breakpoint @ address 0x0000C71C, Size = 2, BPHandle = 0x000A
Setting breakpoint @ address 0x0000C754, Size = 2, BPHandle = 0x000B
Setting breakpoint @ address 0x0000CEDC, Size = 2, BPHandle = 0x000C
Performing single step...
ERROR: CPU is not halted
ERROR: Can not read register 15 (R15) while CPU is running
...Breakpoint reached @ address 0x00000000
Reading all registers
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running

After a stack of failed register reads and failed memory reads around 0xDEADBEEF, the debugger recovers with the following output:

Reading 64 bytes @ address 0xDEADBEC0
WARNING: Failed to read memory @ address 0xDEADBEC0
WARNING: Failed to read memory @ address 0xDEADBEEC
Received monitor command: clrbp
Received monitor command: reset
Resetting target
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x000104E0)
Read 2 bytes @ address 0x00014F08 (Data = 0xB508)
Received monitor command: regs

The c-code has just executed an xQueueReceive(..), and returned successfully (the crash is on the first instruction of the switch(evt.event_type), and the value of evt.event_type is zero (sending_data).

        if(pdFAIL == xQueueReceive(event_queue, &evt, BLOCK_TIMEOUT)){
            assert(!event_queue);
            evt.event_type = tx_done;
        }

        switch(evt.event_type){      << Crash happens here - loading evt.event_type to r3
        case sending_data:

Here is the corresponding assembler, with the crash point marked:

0000c702:   bl      0x864 <xQueueGenericReceive>
0000c706:   mov     r3, r0
0000c708:   cmp     r3, #0
0000c70a:   bne.n   0xc724 <send_frame+160>
341                 assert(!event_queue);
0000c70c:   ldr     r3, [pc, #168]  ; (0xc7b8 <send_frame+308>)
0000c70e:   ldr     r3, [r3, #0]
0000c710:   cmp     r3, #0
0000c712:   beq.n   0xc720 <send_frame+156>
0000c714:   ldr     r2, [pc, #176]  ; (0xc7c8 <send_frame+324>)
0000c716:   movw    r1, #341        ; 0x155
0000c71a:   ldr     r0, [pc, #168]  ; (0xc7c4 <send_frame+320>)
0000c71c:   bl      0x22d4 <__assert>
342                 evt.event_type = tx_done;
0000c720:   movs    r3, #3
0000c722:   strb    r3, [r7, #8]
345             switch(evt.event_type){
0000c724:   ldrb    r3, [r7, #8]                << Executing this instruction causes the crash

Solution

  • I usually know I'm getting desperate when I start blaming the hardware, but this time it was (sort-of) the case. A separate thread was turning on a radio power amplifier, & my Power supply current limit was tripping. The other thread was always activating exactly when this instruction was executing, so crashing the whole board.