FreeRTOS ARM皮质从systick硬件故障升级

在特殊情况下，我遇到硬件故障异常。 ICSR表明这是从systick升级（等待例外= 15）。FreeRTOS ARM皮质从systick硬件故障升级

任何想法如何会发生这种情况？

我的猜测是，它的某种死锁的。

任何建议如何追踪此（无Atmel工作室）？

我使用FreeRTOS的7.5.2。

UPDATE：

我增加了一些故障寄存器的输出转储。因此，这的确是一个系统定时器总线故障中断标志：

EXCEPTION HANDLER 
- ICSR active exception: 3 
- ICSR pending exception: 15 
- ICSR pending interrupt: 0 
- Hardfault status: 0x40000000 
    - Memory fault status: 0x00 
    - Bus fault status: 0x04 
    - Usage fault status: 0x0000

我能够追查例外，一个FreeRTOS的电话：

vTaskDelay(10/portTICK_RATE_MS);

应用程序有2项任务：

优先级为2的任务（xTaskCreate的参数）
优先级为1的任务

任务1进入一个被信号量锁定的区域，并触及上面提到的行。任务2应该醒来并运行，直到它也想进入锁定区域。

来源

2017-01-24 Martin

只是因为总线故障与systick挂起，并不意味着它与systick有任何关系。硬故障状态为强制，错误为IMPRECISERR（不准确的数据错误）。我强烈建议您阅读下面的Richard链接，特别是处理不精确的错误。当调用vTaskDelay时，操作系统会在其他地方出现。我怀疑问题发生在与你想象的完全不同的地方！ –

我想你们误解了ICSR。这并不是说异常已经从SYSTICK升级，并且与硬故障没有任何关系。

首先您需要查看HFSR（硬故障状态寄存器）。如果强制设置意味着它可能会从总线故障，存储器故障或使用故障升级（我怀疑它会被强制）。如果是，请查看CFSR，看看您有什么样的错误。

然后你可以从这里进一步调试。如果它是一种总线错误（很有可能），那么你需要查看CFSR中的BFARVALID位。如果这设置，那么你很幸运，因为BFAR寄存器将包含故障地址。如果没有设置，事情会变得更加困难！裸记住那么CFSR实际上是多个寄存器中的一个，这样需要正确解码，某些位是类型总线错误的和其他人MEM男人故障等。

来源

2017-01-24 15:32:07

明天我会检查你的建议和MCU规格 - 然后检查系统。这可能需要一些时间... – Martin

感谢你们（也@richard）的帮助。你的提示都有帮助。这个提示和上面的评论有点帮助，所以我接受了这个答案。顺便说一句：这个bug是未初始化的指针上的一个空闲的指针，发生在一个角落的情况下。 :-( – Martin

我不知道你为什么会认为[软件？]死锁会导致硬件硬故障，但一些关于调试硬故障的信息可以在这里找到：http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

我还建议更新版本FreeRTOS作为更新版本更多assert（）语句包括捕获中断优先级和其他中断相关的误用和错误配置。

来源

2017-01-24 16:56:04 Richard

感谢@Richard再次找到这个链接，我非常想更新FreeRTOS的一个新版本，但是在版本8.x中，API已经发生了很大的变化。上次我从7.3.0更新到7.5.2这已经很痛苦（很多工作）。 – Martin

FreeRTOS ARM皮质从systick硬件故障升级

回答

相关问题