为什么 cortex-m3 会在 gdb 中重置为地址 0?

发布于 2024-10-15 03:49:50 字数 1200 浏览 3 评论 0原文

我正在为 Stellaris LM3S8962 cortex-m3 芯片构建交叉编译工具链。我编写的测试 C++ 应用程序将执行一段时间然后出现故障。当我尝试访问内存映射硬件设备时会发生该错误。目前我的工作假设是我在启动序列中缺少一些必要的芯片初始化。

我想了解的是为什么 gdb 中的执行会停止并且程序计数器设置为 0?我的向量表位于 0x0,但第一个值是堆栈指针。难道我不应该进入向量表中指定的故障处理程序之一吗?

(gdb) 
187     UARTSend((unsigned char *)secret, 2);
(gdb) cont

Continuing.

lm3s.cpu -- clearing lockup after double fault


Program received signal SIGINT, Interrupt.
0x00000000 in g_pfnVectors ()

(gdb) info registers 
r0             0x1      1
r1             0x32     50
r2             0xffffffff       4294967295
r3             0x0      0
r4             0x74518808       1951500296
r5             0xc24c0551       3259762001
r6             0x42052dac       1107635628
r7             0x20007230       536900144
r8             0xf85444a9       4166272169
r9             0xc450591b       3293600027
r10            0xd8812546       3632342342
r11            0xb8420815       3091335189
r12            0x3      3
sp             0x200071f0       0x200071f0
lr             0xfffffff1       4294967281
pc             0x1      0x1 <g_pfnVectors+1>
fps            0x0      0
cpsr           0x60000023       1610612771

工具链基于gcc、gdb、openocd。

I am building a cross-compile toolchain for the Stellaris LM3S8962 cortex-m3 chip. The test c++ application I have written will execute for some time then fault. The fault will occur when I try to access a memory-mapped hardware device. At the moment my working hypothesis is that I am missing some essential chip initialization in my startup sequence.

What I would like to understand is why would the execution in gdb get halted and the program counter be set to 0? I have the vector table at 0x0, but the first value is the stack pointer. Shouldn't I end up in one of the fault handlers I specify in the vector table?

(gdb) 
187     UARTSend((unsigned char *)secret, 2);
(gdb) cont

Continuing.

lm3s.cpu -- clearing lockup after double fault


Program received signal SIGINT, Interrupt.
0x00000000 in g_pfnVectors ()

(gdb) info registers 
r0             0x1      1
r1             0x32     50
r2             0xffffffff       4294967295
r3             0x0      0
r4             0x74518808       1951500296
r5             0xc24c0551       3259762001
r6             0x42052dac       1107635628
r7             0x20007230       536900144
r8             0xf85444a9       4166272169
r9             0xc450591b       3293600027
r10            0xd8812546       3632342342
r11            0xb8420815       3091335189
r12            0x3      3
sp             0x200071f0       0x200071f0
lr             0xfffffff1       4294967281
pc             0x1      0x1 <g_pfnVectors+1>
fps            0x0      0
cpsr           0x60000023       1610612771

The toolchain is based on gcc, gdb, openocd.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

深居我梦 2024-10-22 03:49:50

GDB 很高兴地给了你一些线索:

双重故障后清除锁定

您的 CPU 处于锁定状态。这意味着它无法运行其“硬故障”中断处理程序(可能其向量中有一个 0)。

当我忘记给外设“供电”时,我通常会得到这些信息,由此产生的总线错误首先升级为“硬故障”,然后升级为锁定状态。顺便说一句,应该在你的 MCU 手册中提到。

GDB happily gave you some clue:

clearing lockup after double fault

Your CPU was in locked state. That means it could not run its "Hard Fault" Interrupt Handler (maybe there is a 0 in its Vector).

I usually get these when I forgot to "power" the periperial, the resulting Bus Error escalates first to "Hard Fault" and then to locked state. Should be mentioned in the manual of your MCU, btw.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文