因終端有遠程升級的需求，終端固件划分為兩個部分。
數據傳輸方式：GPRS
MCU：STM32F301C8T6 16k+64k
1、OTA部分：ota部分程序的功能是通過GPRS模組接收服務器下發的app文件。並將bin文件寫入在app固件對應的Flash區。完成bin文件的接收和寫入后，清除flash中的ota更新請求標記，然后系統主動軟件復位。系統復位重啟后檢測更新標記已經被清除，直接跳轉至app代碼區。在每次系統復位之后，系統都是從ota部分代碼區開始運行的，進入ota代碼區后讀取flash中是否有更新請求標記，如果有就通過GPRS請求更新數據包，如果沒有就直接跳轉到app代碼區。ota代碼區flash地址設置為0X08000000--0X08005800,大小為22k，實際ota代碼大小為0X5080 小於21k。注意，該代碼區的大小必須為0X200的整數倍。
2、APP部分：app部分是正常的業務代碼，具體內容與實際項目內容相關聯。除了業務邏輯的處理外，app代碼需要通過GPRS接收服務器的更新請求，並將更求請求標記寫入Flash中，寫入完成后，系統主動軟件復位。app部分代碼flash起始地址為0X08005080，大小為0XA800。地址分為在MDK中進行設置。
問題描述1：
由於mcu資源限制，隨着app處理的問題增加，app的代碼變多，生成的app.bin大小也接近系統的flash限制。於是對app工程設置的優化選項。優化等級設為2級優化，優化后，生成的bin文件小了4k左右。當系統的1.3版本經過優化后，業務邏輯仍然能正常處理。但導致系統進行ota時程序死機。ota代碼無法正常完成更新。系統從此停留在ota代碼區的死機部分。在1.2版本的app工程中，進行OTA升級時未出現死機的情況，測試板子運行正常。
問題描述2：
在1.2版本的app工程中，進行了小批量的OTA升級測試，一共進行升級的設備共84台，設備分布在實際的使用環境中。其中發現1台出現於1.3版本一樣的死機情況。
問題分析：
系統死機后，在ota工程中死機的前一步分加入關鍵變量值的打印，然后重新燒錄進行ota。發現控制循環的變量值發生了變化。
在隊列清空函數中，循環結束變量是當前隊列的長度和位置的和，變量類型均為u16 ，這兩個變量的值在正常的情況下被初始化為0。出現異常時其和的值變成256. 此時在for循環中自增變量的類型為u8，最大值為255.故無法跳出此循環，進而出現系統不能繼續往后運行的情況。
在1.2版本中出現死機的設備關鍵變量值的打印，隊列的長度和位置的和的值為12965，仍然不能跳出循環。
產生問題的可能原因：
1、OTA部分與APP部分RAM區重合導致數據干擾。
由於在兩個工程中做了Falsh區的隔離，但未對RAM區進行隔離，可能會導致OTA工程中全局變量的初始值被修改的情況。
測試實驗：在MDK中對RAM區進行隔離設置。該問題仍然出現，故排除RAM區重合的原因。
2、原因分析中。。。
解決方案：
更改OTA代碼中隊列清除函數中循環變量的類型為u16，保證變量的初始值被修改也能跳出循環。
相關連接：
https://community.st.com/message/192335-problem-about-stm32f301-iap