0
我正在爲使用相對複雜的通信接口的ARM Cortex-M3編寫啓動加載程序;這與實際應用程序使用的相同。該應用程序使用Keil的RTX作爲其內核，通信棧依賴於它。當然使用GCC。Keil RTX啓動時的控制
引導加載程序執行以下基本步驟：
- 在啓動時，一個有效的應用圖片檢查;如果沒有可用的，則進入升級模式;
- 它檢查按鈕按鈕作爲進入升級模式的請求;如果發現，它進入升級模式。
- 找到一個有效的圖像，並沒有升級請求，它「啓動」應用程序。
這是相當簡化的，但它充分描述了我們的目的情況。
令人驚訝的證明困難的最後一個問題是啓動應用程序。這個想法是禁用中斷，設置向量表，堆棧指針，並跳轉到新向量表中的應用程序的重置向量。所有這些工作只是桃色，除了不久之後，我得到一個硬性故障。
通過實驗，如果我在一個簡單的引導程序（不使用RTX或當然，通信堆棧）中執行此操作，那麼引導到應用程序工作正常。所以看來RTX是個問題。
事情是，真正的引導程序在進入升級模式之前不需要RTX。所以明顯的做法是在我們確定需要之前不啓動RTX;然而，它似乎被入侵到了啓動代碼中，所以當我進入bootloader代碼時，已經太晚了;的確，bootloader的main（）函數已經是一個線程了！
最好的方法似乎是不開始RTX（太糟糕了，我沒有使用FreeRTOS！），直到我需要它;然而，這似乎需要一些黑客攻擊。另一種方法是以某種方式禁用所有中斷和異常，但由於某種原因，我還沒有成功。有沒有人有這兩種方法的例子？
因此，引導程序和應用程序都是基於RTX的？如果是這樣，最好的選擇可能是完全改變計劃 - 將所有內容鏈接到一個程序中，運行初始檢查作爲啓動任務，然後啓動「升級」或「應用程序」任務爲適當。通過不重複單獨的「引導加載程序」和「應用程序」映像之間的「相對複雜的」通信代碼，這也可以節省您的閃存空間。 – Notlikethat
似乎需要從RAM或其他程序運行，並覆蓋引導加載程序（因爲它是正在上傳的應用程序的一部分！）;恐怕，這會使系統太過混亂。但有趣的想法。很明顯，當我說「相對複雜」時，我誤導了你;雖然它很複雜，但並不是很大 - 我的引導程序大約是20 KB，我的應用程序是80 KB，並且該設備有1 MB！ – Bob