MM32 IAP升級-APP篇
IAP（In Application Programming）即在應用程序編程，是一種自舉程序。由於產品固化後不容易採用傳統下載器更新固件使得許多產品中內置Bootloader程序用於遠程更新固件，有的應用產品在產品固化後，只預留了USB、UART等通信介面，所以如果需要固件更新，只能考慮使用預留的通信介面進行更新固件操作，在一些上網設備或者無線設備上，也會使用到該功能，例如通過BLE、WIFI等無線通信進行固件更新，我們稱為OTA（over the air technology)）空中下載技術，也是利用到了IAP升級的原理。
實現IAP功能時，即用戶程序需要在運行中對自身的功能程序進行更新操作，需要在設計固件程序時編寫兩個項目代碼，第一個項目程序不執行正常的功能操作，而只是通過某種通信方式（如USB、UART、SPI等通信介面）接收程序或數據，執行對第二部分代碼的更新，稱之為Bootloader程序；第二個項目代碼才是真正的功能代碼，稱之為APP程序，同時APP程序不僅可以在flash中運行也可以在SRAM中運行。這兩部分項目代碼都同時燒錄在Flash的不同地址範圍，一般從最低地址區開始存放Bootloader，緊跟其後的就是APP程序，MM32系列晶元flash容量有16k - 512k不同的容量，用戶在設計IAP固件分區時需要規劃好兩個項目代碼的地址分配。當晶元上電後，首先是第一個項目代碼開始運行，它作如下操作：
1、檢查是否需要對第二部分代碼進行更新（用戶可以在此過程中加入一些校驗功能，判斷是否需要更新正確的代碼）
2、如果不需要更新則轉到第四步（校驗出現錯誤，繼續執行原始的功能程序）
3、執行更新操作
4、跳轉到第二部分代碼執行
第一部分代碼必須通過其它手段，如SWD等方式燒入；第二部分代碼可以使用第一部分代碼IAP功能燒入，也可以和第一部分代碼一起燒入，以後需要程序更新時再通過第一部分IAP代碼更新。
有的用戶在IAP開發中用Bootloader程序+ APP程序1 + APP程序2的方式，這個方式有一個好處就是如果APP更新不成功或者校驗錯誤還可以跳轉到另一個APP中運行功能程序，可以保證不會出現無固件的情況，防止設備變成板磚或死機等情況，不過該方法需要大容量的flash晶元或者外掛flash存儲晶元，需要用戶在開發中判斷適合哪一種方式，原理與Bootloader程序+ APP程序相同，主要區別就是跳轉的位置實現方法。
1、IAP負責通過flash的flag去判斷啟動app1還是app2
2、app1和app2中通過UART或USB收數據去互相更新，比如，當前運行的是app1上就去更新app2，並且設置相應flag，最後軟體重啟跳到IAP判斷flag啟動哪一個的app2。
有的用戶產生疑問，如果固件更新後，程序運行在APP功能程序中，假如需要第二次更新固件程序該如何處理呢？最簡單直接的方法就是：設備做斷電操作或者複位操作，在Bootloader程序中會做判斷執行Bootloader或APP。如果用戶希望不做斷電或複位操作，建議使用以下方式，如果用戶在更新固件完成後，程序會跳轉到APP程序中運行，如果需要第二次更新固件需要程序再次跳轉到Bootloader程序，執行更新程序，如果用戶在設備中有一個功能控制按鍵，可以利用該按鍵設備判斷是執行Bootloader程序或者APP程序，在更新完成後，讀取按鍵狀態，判斷是進入APP區域運行或者進入Bootloader區域，在主循環中然後再做判斷是執行執行Bootloader程序或者APP程序，這樣就可以實現二次更新下載程序，在這裡介紹一種客戶常用的方式，如何MM32用戶有更好的操作方案，歡迎大家通過MM32論壇或者MM32 QQ群等交流途徑提出更好的方案，方便大家一起討論優缺點。
APP程序二次更新操作配置
在主程序的循環函數可以看到，進while(1)後，我會去判斷key3的電平狀態，如果key3被按下，初始化用戶程序的堆棧指針，生成跳轉函數，實際失去app複位地址去執行複位操作，程序將跳轉到Bootloader區域執行Bootloader，等到固件更新。
在前期的《MM32 IAP中斷向量表重定義》的文章中有給大家介紹中斷向量表的重定義的配置方法，在Cortex-M3內核的MCU上可以通過設置SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET；該寄存器的值來實現中斷向量表的重定義。但在MM32L0xx系列以Cortex-M0為內核是沒有SCB->Vector寄存器，需要重新將48個中斷向量表填充為APP的中斷向量表並開啟RCCAPB2ENR中SYSCFGEN位打開SYSCFG配置時鐘配置SYSCFG->CFGR1中MEM_MODE，配置為0x3，嵌入式SRAM映射到首地址（系統複位後會自動根據BOOT引腳電平配置這2位，設置這2位作用是系統從哪裡獲取向量表，複位後自動從ROM映射的起始地址取向量表，這裡向量表已經被更新了，所以設置為0x3使得SRAM中的向量表地址被映射到起始地址）。
1、將中斷向量表放入到RAM的起始地址（只需要在應用程序中保留RAM起始地址的0x100大小不使用即可）。
2、在bootload中將應用程序的中斷向量表從Flash中拷貝到RAM中。
3、設置MM32L073中斷向量表位於RAM中。
APP程序配置流程：
MM32的flash的起始地址是0x08000000，程序文件就是從這個地址開始寫入。本次實驗使用的MM32L073PF有128k的flash，所以從0x08000000至0x08020000的128k空間是程序存儲的空間。設置起始地址（Start）為0X08010000，即偏移量為0X10000（64K位元組），APP用的FLASH空間（Size）只有0X20000-0X10000=0X10000（64K位元組）大小了。設置好Start和Size，就完成APP程序的起始地址設置。這裡的64K位元組，需要用戶根據Bootloader程序大小進行選擇，在應用開發時設計者根據應用的需求和晶元的flash容量合理分配空間，注意不要出現溢出等情況，有很多客戶在使用IAP功能時，會進入hardfault，最後查找發現是flash出現溢出，這個在開發時需要注意。
Keil默認生成的是hex文件（ASCII碼的文本文件，HEX文件內部的信息已經包括了地址），但是IAP升級的是.bin文件（包括了純粹的二進位數據，在燒寫時用戶需要指定地址信息）。用戶可以在APP工程中先生成hex文件，然後使用靈動微電子為方便客戶轉換文件的hex2bin工具，使用keil有自帶的格式轉換工具fromelf.exe，來實現.axf文件到.bin文件的轉換。有興趣的用戶可以自行百度深入了解操作方法。
靈動微電子hex2bin工具
本次實驗主要向大家介紹了IAP的基本理論和APP程序編寫方法，下一期將向大家介紹在MM32L073PF上實現Bootloader程序。
關於靈動微電子
靈動微電子股份有限公司（股票代碼：833448，股票簡稱：靈動微電）是國內專註於MCU產品與MCU應用方案的領先供應商，是中國工業及信息化部和上海市信息化辦公室認定的集成電路設計企業，同時也是上海市認定的高新技術企業。自2011年3月成立至今，靈動微電子已經成功完成數百餘MCU產品的設計及推廣，靈動微電子目前已批量供貨的基於ARMCortex-M0及Cortex-M3內核的MCU產品包括：針對通用高性能市場的MM32F系列，針對超低功耗及安全應用的MM32L系列，具有多種無線連接功能的MM32W系列，電機驅動及控制專用的MM32SPIN系列，以及針對超小尺寸及超高集成度的MM32P系列等，以滿足客戶及市場多領域、多層次的豐富應用場景需求。
靈動微電子立足本土，洞悉市場，貼近客戶，以為客戶提供「保姆式」的全方位支持為特色，堅持「專業、可靠、便捷、高效」的服務理念，貫徹差異最大化，成本最優化的經營策略，不斷強化自身生態價值，維護良好產品品牌。公司在銷售初期就與客戶充分接觸，為客戶提供產品整體解決方案，從產品功能定義、市場競爭力分析到演算法整合、軟體驅動、應用常式等都深入參與，為客戶提供精準的市場分析和全面的應用方案，幫助客戶把握好成功的每一個重要環節。
TAG:靈動微電MMCU |