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

0

[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
eclipse
arm
segger-jlink
asked on Stack Overflow Apr 7, 2020 by harry courtice • edited Apr 7, 2020 by harry courtice

1 Answer

0

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.

answered on Stack Overflow Apr 9, 2020 by harry courtice

User contributions licensed under CC BY-SA 3.0