Eclipse MCU J-Link 调试器在 ldrb r3，[r7，#8] 上崩溃。地址有效 - [编辑 - 硬件问题]

Posted 2023-02-14

【中文标题】Eclipse MCU J-Link 调试器在 ldrb r3，[r7，#8] 上崩溃。地址有效 - [编辑 - 硬件问题]

【英文标题】：Eclipse MCU J-Link Debugger Crash on ldrb r3, [r7, #8]. Addresses are valid - [Edit - Hardware Issue]

【发布时间】：2020-07-19 16:58:15

【问题描述】：

[编辑] 这原来是硬件问题。一个单独的线程正在打开无线电功率放大器，我的电源电流限制正在跳闸。另一个线程总是在这条指令执行时准确地激活]

我在调试我的项目时遇到了这个崩溃问题。

CPU 是 SAM4LS8 (Cortex-M4)。我正在使用 Eclipse MCU 2018/09 使用 SEGGER J-Link 调试器进行调试。 使用 FreeRTOS 8.2.1 和 Atemel ASF。

我有一条特定的指令，当我单步执行它时会导致调试器崩溃。我相信指令和地址是正确的，所以我不认为指令本身就是问题所在。

如果您对这个问题很熟悉，非常感谢您的意见。快要死了。

ldrb r3,[r7,#8]

r7 的值为 20004490（与 lr 中的值相同）。被访问的变量是一个自动变量，调试器按预期成功地从地址 0x20004498 检索到该变量的值。当我尝试单步执行指令时，我在调试器控制台上得到以下信息。单步似乎没有正确停止。 （我已经包含了调试器在步骤之前成功读取变量值的输出）。

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

在 0xDEADBEEF 附近的寄存器读取失败和内存读取失败后，调试器恢复并显示以下输出：

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

c-code刚刚执行了一个xQueueReceive(..)，成功返回（崩溃在switch(evt.event_type)的第一条指令，evt.event_type的值为零(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:

这里是对应的汇编器，标出了崩溃点：

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

【问题讨论】：

我非常非常强烈建议下载 [GNU Arm Embedded Toolchain Version 9-2019-q4-major ](developer.arm.com/tools-and-software/open-source-software/…)，并使用包含的编译器/GDB：这将从图片中删除您正在使用的工具链/GDB（与 MCU Eclipse 捆绑在一起？）。使用最新版本的 JLink (v6.70c) 也可能有用。

在你进入这条指令之前，r7中的地址是什么？

@frant - 谢谢。是的，工具链随项目一起提供。感谢您的建议，但它原来是硬件。现在追逐另一个 - 这里是***.com/questions/61115980/…。

@old_timer - 我确实注意到了 r7 的值 - 与 LR 相同，但根据编辑，结果证明是硬件问题。感谢您的关注。如果你觉得无聊，可以在这里看看我的最新问题：***.com/questions/61115980/…Cheers，

doh okah 我现在看到 r7 的值了。

【参考方案1】：

我通常知道当我开始责怪硬件时我会变得绝望，但这次是（有点）情况。一个单独的线程正在打开无线电功率放大器，我的电源电流限制正在跳闸。另一个线程总是在这条指令执行时准确地激活，所以整个板子都崩溃了。