使用freeRTOS在stm32上隨機分配神祕值（A5A5A5A5和FFFFFFFF）的指針使用freeRTOS導致硬故障

我遇到硬故障，出現在看似隨機的時間，其中指針指向地址A5或FF（我允許的內存空間很遠低於80000000及以上）。它似乎總是與這兩個值相同的指針。使用freeRTOS在stm32上隨機分配神祕值（A5A5A5A5和FFFFFFFF）的指針使用freeRTOS導致硬故障

我正在使用運行STM32F205RE處理器的嵌入式系統，該處理器與發生此錯誤的fm/bluetooth/gps芯片（稱爲cg2900）進行通信。

使用調試器我可以看到指針分別在幾個testruns期間指向地址A5和FF。然而，它似乎隨機發生，有時我可以運行測試一小時而不失敗，而其他時間崩潰20秒。

我運行freeRTOS作爲調度程序以在不同任務之間切換（一個用於無線電，一個用於藍牙，一個用於其他定期維護），這可能會以某種方式干擾。

這可能是什麼原因？當它運行定製硬件時，不能排除它是一個硬件問題（可能）。任何指針（沒有雙關語意）如何處理調試問題？

編輯：

經過進一步調查，它似乎是很隨意的地方它崩潰，而不僅僅是特定的指針。我用了一個hardfault處理程序來獲取這些寄存器的值選擇（十六進制的值）：飛機墜毀前

半長遠來看（分鐘）：

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

似乎在同一點崩潰的大部分時間。我根據以前的建議調整了內存，但我似乎仍然有同樣的問題。

謝謝你的時間！

親切的問候

來源

2012-12-29 ChewToy

這些看起來像故障安全魔術字節。你確定你沒有一個懸空的指針，一個取消引用的NULL或返回的本地數組？ – 2012-12-29 09:15:24

@ H2CO3是的，他們確實看起來像魔術字節。指針指向數組的基數（全局作用域），並且我已經有了一個檢查條件，以確保我不會在其外寫入數據。指針本身一旦被初始化爲數組的基礎就決不會被賦值。 – ChewToy

如果你可以添加一些實際的代碼，這將有所幫助。 – 2012-12-29 10:25:21

打開它，這個問題是由存儲器引起的。當我以最高速度（120 Mhz）運行處理器並使用1.8伏電源（主要爲3伏設計）時，我遇到了一些與內存有關的競爭情況。通過使用更高的等待狀態來解決它。

來源

2013-01-15 12:16:03 ChewToy

在你的評論指出，這項指針明確分配一次，然後永遠不會寫入。在這種情況下，您至少應該聲明它const並使用初始化而不是賦值，例如

arraytype* const ptr = array ;

這將允許編譯器檢測到任何明確的寫入。但是，指針被一些無關的編碼錯誤破壞的可能性更大。

Coretx-M3片上調試支持數據訪問斷點;你應該在有問題的指針上設置這樣一個斷點，以便所有對它的寫入訪問都被捕獲。您將在初始化過程中休息一下，然後在修改之後 - 有意或無意的。

可能的原因是相鄰陣列或線程堆棧溢出。

來源

2012-12-29 11:27:39 Clifford

感謝您的反饋！它不是一個常量的原因是代碼可以使用幾個單獨的緩衝區，具體取決於它正在運行的特定設備上的當前功能集。僅僅爲了調試的目的，我現在試着把它設爲const，編譯器似乎仍然接受代碼，所以這似乎不是問題。 – ChewToy

就數據訪問斷點而言，我該如何去激活這些斷點？我無法在Google或ST網站/文檔上找到任何詳細信息。我使用編輯器Ride7並通過Rlink Pro進行調試，但在IDE內部找不到此功能。任何人有任何建議或如何手動設置它的例子（通過asm代碼或什麼）？ – ChewToy

@ChewToy：我還沒有使用過RIDE，但是谷歌搜索建議也許：*調試 - >高級命令 - >高級斷點*。我建議你參考你的產品手冊;該功能可能是目標和/或調試器硬件特定的。 – Clifford

如果你試圖重新定位陣列和相同的問題仍然存在，

那麼一些任務溢出。

至於你提到，你正在使用FreeRTOS操作系統，因爲行爲是隨機的可能，什麼是錯的您的設置在電話STACK_SIZE到xTaskCreate

當分配的大小小於你這通常發生真的需要。

如果您閱讀有關usStackDepth的文檔，您注意到代表的是乘數而不是字節數。

我個人排除硬件問題在您的嵌入式板卡，我將專注於FreeRTOS操作系統的配置問題

來源

2012-12-29 21:38:41 RTOSkit

感謝您的回覆！情況可能很好。我確實使用過xTaskCreate，好像它是字節數的大小！當我在新年前夕回到工作崗位時，我會進一步考慮進行一些測試 – ChewToy

我確實有你提出的問題，但似乎沒有幫助。我仍然遇到和以前一樣的問題。雖然我仍然同意它看起來像溢出 – ChewToy

看着你添加的數據，我注意到你的「鏈接寄存器」總是指一個RAM位置，並且一旦引用端口DMA1 ... 這使我認爲DMA傳輸初始化被更高優先級的任務中斷，所以你應該保護你的代碼到一個序列xSemaphoreTake（...）〜xSemaphoreGive（...）你可以閱讀更多關於[互斥]（http：// www.freertos.org/Real-time-embedded-RTOS-mutexes.html）。 – RTOSkit

使用freeRTOS在stm32上隨機分配神祕值（A5A5A5A5和FFFFFFFF）的指針使用freeRTOS導致硬故障

回答

相關問題