5

我遇到了一个硬故障问题，它出现在看似随机的时间，其中一个指针指向地址 A5 或 FF（我允许的内存空间远低于 80000000 及以上的内存空间）。这两个值似乎总是同一个指针。

我正在使用运行 STM32F205RE 处理器的嵌入式系统，该处理器与发生此错误的名为 cg2900 的 fm/蓝牙/gps 芯片通信。

使用调试器，我可以看到在几次测试运行期间指针分别指向地址 A5 和 FF。然而，它似乎是随机发生的，有时我可以运行测试一个小时而不会失败，而其他时候它会崩溃 20 秒。

我正在运行 freeRTOS 作为调度程序，以在可能会以某种方式干扰的不同任务（一个用于无线电，一个用于蓝牙，一个用于其他定期维护）之间切换。

这可能是什么原因？由于它正在运行自定义硬件，因此不能排除这是硬件问题（可能）。关于如何解决问题的任何指示（没有双关语）？

编辑：

经过进一步调查，它崩溃的地方似乎是非常随机的，而不仅仅是那个特定的指针。我使用硬故障处理程序来获取这些寄存器的以下值（所有值均为十六进制）：

崩溃前的半长跑（分钟）：

R0 = 1
R1 = fffffffd
R2 = 20000400
R3 = 20007f7c
R12 = 7
LR [R14] = 200000c8  subroutine call return address
PC [R15] = 1010101  program counter
PSR = 8013d0f
BFAR = e000ed38
CFSR = 10000
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

崩溃前很短的运行时间（秒）：

R0 = 40026088
R1 = fffffff1
R2 = cb3
R3 = 1
R12 = 34d
LR [R14] = 40026088  subroutine call return address
PC [R15] = a5a5a5a5  program counter
PSR = fffffffd
BFAR = e000ed38
CFSR = 100
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

另一个短的（秒）：

R0 = 0
R1 = fffffffd
R2 = 20000400
R3 = 20007f7c
R12 = 7
LR [R14] = 200000c8  subroutine call return address
PC [R15] = 1010101  program counter
PSR = 8013d0f
BFAR = e000ed38
CFSR = 1
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

经过很长时间（1小时+）：

R0 = e80000d0
R1 = fffffffd
R2 = 20000400
R3 = 2000877c
R12 = 7
LR [R14] = 200000c8  subroutine call return address
PC [R15] = 1010101  program counter
PSR = 8013d0f
BFAR = 200400d4
CFSR = 8200
HFSR = 40000000
DFSR = 0
AFSR = 0
SCB_SHCSR = 0

似乎大部分时间都在同一点崩溃。我根据之前的建议调整了内存，但我似乎仍然有同样的问题。

谢谢你的时间！

亲切的问候

4

4 回答 4

4

在您的评论中，您提到该指针被显式分配一次，然后从未被写入。在这种情况下，您至少应该声明它const并使用初始化而不是赋值，例如

arraytype* const ptr = array ;

这将允许编译器检测任何显式写入。然而，指针更有可能被一些不相关的编码错误破坏。

Coretx-M3 片上调试支持数据访问断点；您应该在有问题的指针上设置这样的断点，以便捕获对它的所有写访问。您将在初始化时休息一下，然后在修改后休息 - 有意或无意。

可能的原因是相邻数组或线程堆栈溢出。

于 2012-12-29T11:27:39.293 回答
3

如果您尝试重新定位阵列并继续遇到同样的问题，

然后有些任务溢出了。

正如您所提到的，您使用的是 FreeRTOS，并且由于行为是随机的，因此您在调用xTaskCreate时的设置STACK_SIZE可能有问题 这通常发生在分配的大小小于您真正需要的大小时。

如果您阅读有关usStackDepth的文档，您会注意到它表示乘数而不是字节数。

我个人会排除您的嵌入式主板中的硬件问题，我会专注于 FreeRTOS 的配置问题

于 2012-12-29T21:38:41.517 回答
1

原来问题是由内存存储引起的。当我以最高速度（120 Mhz）运行处理器并使用 1.8 伏电源（它主要设计用于 3 伏）时，我的内存出现了一些竞争状况。通过使用更高的等待状态来解决它。

于 2013-01-15T12:16:03.247 回答
0

我还没有准备好完整的问题，但听起来 0xa5a5a5a5a5 值是位解压缩的症状，类似于位腐烂。基本上，0xffffffff = 0b11111111111111111111111111111111 的叠层结构开始剥离，1 的相互偏离。他们甚至可以开始侵入相邻的单词。

于 2019-08-19T16:06:43.263 回答