[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
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.
User contributions licensed under CC BY-SA 3.0