使用freeRTOS导致硬故障的stm32上的指针随机分配的神秘值(A5A5A5A5和FFFFFFFF)

Question

我有一个硬故障的问题，它出现在一个看似随机的时间，指针指向地址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

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

耽误您时间，实在对不起!

亲切的问候

Answer 1

结果表明问题是由内存存储引起的。当我以最高速度(120 Mhz)运行处理器，并使用1.8伏电源(它主要设计为3伏)时，我对内存有一些竞争条件。通过使用更高的等待状态解决了此问题。

Answer 2

在您的注释中，您提到这个指针被显式赋值一次，然后再也不会被写入。在这种情况下，您至少应该将其声明为const，并使用初始化而不是赋值。

arraytype* const ptr = array ;

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

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

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

Answer 3

如果您尝试重新定位阵列并继续处理相同的问题，

则表示某个任务溢出。

正如您所提到的，您正在使用FreeRTOS，并且由于该行为是随机的，因此很可能是在调用时您的STACK_SIZE设置有问题

当分配的大小小于实际需要时，通常会发生这种情况。

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

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

的配置问题