車載終端的功能應(yīng)當(dāng)隨著用戶的需求而變化，因此車載終端的升級維護(hù)也顯得越來越重要。然而，目前大部分車載終端還不具有遠(yuǎn)程升級的功能，必須在現(xiàn)場通過預(yù)留的通信口下載更新程序才能升級，升級維護(hù)相對比較困難而且也增加了成本。針對這樣的情況，本文提出了一種具有可行性的遠(yuǎn)程升級解決方案。監(jiān)控中心只需要發(fā)送一條遠(yuǎn)程升級指令給車載終端，車載終端就能自動的更新自身的固件程序，簡單方便而且安全可靠，還可以讓所有的車輛同時升級。

　　1.遠(yuǎn)程升級的基本原理

    1.1 lAP簡介

    lAP(In Application Programming)是用戶自己的程序在運行過程中對內(nèi)部Flash的部分代碼區(qū)域重新燒寫。要實現(xiàn)lAP功能需要在設(shè)計固件程序時編寫兩個項目代碼，第一個項目代碼為BootLOAder程序，第二項目代碼為UserApp程序，即用戶功能程序。BootLoader程序不執(zhí)行正常的功能操作，只執(zhí)行對第二部分代碼的更新；UserApp程序才是真正的功能代碼，這兩部分項目代碼都同時燒錄在內(nèi)部Flash中。

　　1.2 遠(yuǎn)程升級的基本原理

　　遠(yuǎn)程升級有兩種模式，主動模式和被動模式。主動模式是指車載終端自動檢測是否有新版本的程序需要更新，被動模式是指監(jiān)控中心給車載終端下發(fā)升級指令后車載終端才執(zhí)行遠(yuǎn)程升級操作。本課題中，使用的是被動模式。車載終端收到監(jiān)控中心發(fā)送的遠(yuǎn)程升級指令后，連接遠(yuǎn)程FTP服務(wù)器，建立連接后下載要更新的程序代碼，同時將其寫入車載終端的外部flash中，更新程序代碼下載完畢后，對其進(jìn)行校驗，校驗通過后，自動重啟終端進(jìn)入BootLoader模式，利用lAP技術(shù)重新燒寫User-App程序代碼區(qū)域。燒寫完畢后，跳轉(zhuǎn)到新的UserAPP程序執(zhí)行，然后給監(jiān)控中心發(fā)送遠(yuǎn)程升級成功指令。可以用圖1形象地表示遠(yuǎn)程升級的過程。

圖1 遠(yuǎn)程升級的過程

　　2.遠(yuǎn)程升級系統(tǒng)的設(shè)計與實現(xiàn)

    2.1 車載終端的硬件結(jié)構(gòu)

    車載終端硬件結(jié)構(gòu)如圖2，這里只介紹與遠(yuǎn)程升級相關(guān)的模塊，核心處理器使用ST公司的STM32系列MCU，該系列MCU支持IAP編程技術(shù)，外圍無線通信GPRS模塊使用SIMCOM公司SIM900A，SIM900A的最新軟件版本可以支持FTP協(xié)議，外部大容量存儲器。

圖2 車載終端硬件結(jié)構(gòu)簡圖

　　2.2 Flash空間劃分

    2.2.1 內(nèi)部Flash空間劃分

    STM32的內(nèi)部Flash地址起始于0x08000000，一般情況下，程序文件從此地址開始寫入。STM32是基于ARM CortexM3內(nèi)核的微控制器，其內(nèi)部通過一張“中斷向量表”來響應(yīng)中斷，程序啟動后首先從0x08000004地址取出復(fù)位中斷向量的地址，并跳轉(zhuǎn)到復(fù)位中斷服務(wù)程序，如圖標(biāo)號①所示；在復(fù)位中斷服務(wù)程序執(zhí)行完之后，會跳轉(zhuǎn)到我們的main函數(shù)，如圖標(biāo)號②所示；而main函數(shù)一般都是一個死循環(huán)。在main函數(shù)執(zhí)行過程中，如果收到中斷請求，此時STM32強制將PC指針指回中斷向量表處，如圖標(biāo)號示；然后，根據(jù)中斷源進(jìn)入相應(yīng)的中斷服務(wù)程序，如圖標(biāo)號④所示；在執(zhí)行完中斷服務(wù)程序以后，程序再次返回main函數(shù)執(zhí)行，如圖標(biāo)號⑤所示。整個過程如圖3所示。

圖3 STM32程序運行流程圖

　　BootLoader程序也有自己獨立的中斷向量表、中斷處理例程和主循環(huán)程序，在Flash中加入BootLoade程序后各個程序的地址分配如圖4，其中M為UserApp程序中斷向量表的偏移量，(0x08000000+M)為UserApp程序的起始地址。

圖4 BootLoade程序UserApp程序地址分配圖

　　2.2.2 外部Flash空間劃分

　　外部Flash空間大小為1MB，一共分成16個扇區(qū)，每個扇區(qū)64KB，遠(yuǎn)程升級使用其中的4個扇區(qū)，這4個扇區(qū)又劃分為兩部分，前兩個扇區(qū)作為更新代碼區(qū)，后兩個扇區(qū)作為備份代碼區(qū)。每一次代碼更新成功后都會將更新代碼區(qū)的程序拷貝到備份代碼區(qū)，也就是說備份代碼區(qū)始終保留的是終端最近一次更新成功的代碼。

　　2.3 FTP遠(yuǎn)程文件下載

　　監(jiān)控中心給終端下發(fā)遠(yuǎn)程升級指令的同時會將FTP服務(wù)器的IP、端口號、用戶名、密碼、更新程序的文件名稱和路徑發(fā)送到終端，終端根據(jù)這些參數(shù)通過AT指令配置GPRS模塊，然后連接到FTP服務(wù)器，連接成功后請求下載更新程序文件。由于更新程序文件大小一般為幾十KB，最大不會超過100K。而FTP一次請求不超過1460B，因此需不斷地發(fā)送請求，直到?jīng)]有數(shù)據(jù)可返回為止。所有的更新程序都會暫存在外部Flash的更新代碼區(qū)。圖5表示了這樣一個過程。

圖5 FTP遠(yuǎn)程文件下載流程圖

　　另外，遠(yuǎn)程升級系統(tǒng)可以自適應(yīng)網(wǎng)絡(luò)，根據(jù)網(wǎng)絡(luò)的狀態(tài)調(diào)整數(shù)據(jù)下載的速度。終端和FTP服務(wù)器建立連接后，相當(dāng)于建立一條數(shù)據(jù)鏈路，監(jiān)控中心給終端反饋該鏈路的數(shù)據(jù)容量，終端依此調(diào)整請求數(shù)據(jù)下載的速度，以平衡網(wǎng)絡(luò)負(fù)荷，提高數(shù)據(jù)下載的可靠性。

　　2.4 lAP編程的實現(xiàn)

　　STM32有一個Flash編程和擦除控制器(FPEC)，F(xiàn)PEC模塊是一個寄存器組用以處理Flash的編程和擦除操作。每次復(fù)位后，F(xiàn)PEC模塊是被上鎖的，需要向FPEC模塊控制寄存器寫入一組鍵值序列keyl和key2才可以解鎖，解鎖后可以操作其他寄存器。為了防止對用戶代碼區(qū)的非法訪問，通常Flash的頁(每頁的大小為2KB)是加以保護(hù)的，試圖在受保護(hù)的頁面進(jìn)行編程都會在FPEC模塊中返回一個保護(hù)錯誤標(biāo)志。

　　lAP編程的對象主要是UserApp代碼區(qū)域，在編程前必須先根據(jù)UserApp代碼區(qū)域的起始地址和代碼大小計算出要編程的區(qū)域在flash中的開始和結(jié)束頁號，然后判斷這些頁號是否在受保護(hù)的區(qū)域內(nèi)，在去除保護(hù)后將這些頁統(tǒng)一擦除然后再進(jìn)行編程。由于要更新的程序存儲在外部Flash中，因此在運行l(wèi)AP程序時，需要在內(nèi)存開辟緩存，將外部Flash的代碼讀到緩存中，然后再燒寫到Flash UserApp代碼區(qū)。STM32是以半字(2個字節(jié))的方式對Flash進(jìn)行編程的，每寫入半字后都要從Flash相同的地址再讀出這半字，如果讀出來的值跟寫入的值相同，則繼續(xù)寫入下個半字，否則重寫這半個字，這種情況基本不會出現(xiàn)，但是為了萬無一失，在編寫程序時還是加了這種判斷。在燒寫完整個UserApp程序后，需要將編程過的頁重新設(shè)為寫保護(hù)，然后再將FPEC模塊上鎖。lAP編程的整個過程可以用圖6來表示。

圖6 lAP編程的過程
 

　　2.5 遠(yuǎn)程升級的可靠性

　　對于車載終端來說，可靠性永遠(yuǎn)都是最重要的。遠(yuǎn)程升級屬于危險系數(shù)比較高的一個操作，因此需要對造成遠(yuǎn)程升級失敗的各種情況做分析，并制定好解決方案，以確保升級的可靠性。下面就具體地分析，在目前的技術(shù)條件下遠(yuǎn)程升級過程中可能會出現(xiàn)的一些不穩(wěn)定因素。

　　1)網(wǎng)絡(luò)不穩(wěn)定，文件下載一半就中斷了。這種情況是可能存在的，大部分車載終端使用的是GPRS網(wǎng)絡(luò)，GPRS網(wǎng)絡(luò)并沒有覆蓋到每一個地方，特別是在山區(qū)，中繼站的密度相對較小，那么離中繼站比較遠(yuǎn)的地方信號比較弱甚至沒有信號，此時FTP連接最容易斷開，造成文件下載失敗。如果FTP連接斷開，終端是可以檢測到了，如果終端檢測到這種情況，會保存已經(jīng)下載的文件數(shù)據(jù)，然后重新建立連接，請求下載余下的部分，如果連續(xù)幾次都失敗，就認(rèn)為本次升級失敗，然后將升級失敗的情況報告給監(jiān)控中心。

　　2)下載的更新文件中部分內(nèi)容出現(xiàn)錯誤或丟失其中某些內(nèi)容。雖然FTP協(xié)議是一種建立連接的可靠協(xié)議，但是誤碼率并不是絕對的零。因此我們假設(shè)這種情況是存在的，當(dāng)一個更新文件下載完畢后根據(jù)約定的規(guī)則會對文件進(jìn)行校驗，如果校驗結(jié)果與從監(jiān)控中心收到的校驗信息不同，則認(rèn)為下載的更新文件有錯誤，丟棄更新文件然后重新下載。另外GPRS模塊和MCU是通過串口通信的，在升級過程中必須將該串口置于最高優(yōu)先級，否則下載的更新文件極易在串口傳輸中丟失某些字節(jié)造成升級失敗。

　　3)在lAP編程的過程中出現(xiàn)錯誤。如果在lAP編程過程中出現(xiàn)錯誤，新的UserAPP程序是不能正常的運行的，在跳轉(zhuǎn)到UserAPP程序執(zhí)行之前看門狗是打開的，如果UserAPP不能正常運行，則不能執(zhí)行喂狗操作，在喂狗時間到后系統(tǒng)就會自動重啟進(jìn)入BootLoader程序，在BootLoader程序中可以檢測到上一次更新失敗，然后會重新執(zhí)行l(wèi)AP編程操作，如果連續(xù)幾次升級失敗，說明更新程序有問題，最后BootLoader程序會加載備份程序代碼，將系統(tǒng)恢復(fù)到升級之前的狀態(tài)。

　　2.6 遠(yuǎn)程升級系統(tǒng)的總體實現(xiàn)

　　2.6.1 遠(yuǎn)程升級系統(tǒng)的總體實現(xiàn)

　　FTP遠(yuǎn)程文件下載，lAP編程這兩個部分實現(xiàn)后，再加入對遠(yuǎn)程升級系統(tǒng)可能出現(xiàn)的意外情況的處理，那么整個遠(yuǎn)程升級系統(tǒng)基本就實現(xiàn)了。圖7，表示出遠(yuǎn)程升級系統(tǒng)的總體實現(xiàn)過程。

圖7 遠(yuǎn)程升級系統(tǒng)的總體實現(xiàn)流程圖

　　2.6.2 遠(yuǎn)程升級系統(tǒng)的測試

　　以上分析過3種可能導(dǎo)致遠(yuǎn)程升級失敗的情況，除了第三種情況沒有辦法模擬，分別模擬了第一種和第二種情況。第一種情況，遠(yuǎn)程升級過程中，主動斷開FTP服務(wù)器的網(wǎng)絡(luò)，那么終端必定不會下載到完整的更新程序，造成更新失敗，測試結(jié)果如表1。

表1 升級過程中斷開FTP服務(wù)器網(wǎng)絡(luò)

　　第二種情況，預(yù)先生成更新文件的校驗信息，傳送給終端，然后隨機將更薪程序文件中某些字節(jié)去掉，終端下載的是不完整的更新程序，必定校驗通不過，造成升級失敗，測試結(jié)果如表2。

表2 更新程序文件部分字節(jié)丟失

　　最后測試了在網(wǎng)絡(luò)良好的條件下的升級情況，一共測試了50次，每一次升級過程都在兩分鐘完成，沒有失敗的情況，測試結(jié)果如表3，因此這樣的升級系統(tǒng)是安全可靠的。

表3 網(wǎng)絡(luò)良好條件下測試

　　3.結(jié)束語

　　經(jīng)過多次測試，該升級系統(tǒng)具有比較高的可靠性。未來隨著3G網(wǎng)絡(luò)的普及，車載終端無線通信模塊若使用3G模塊，該升級系統(tǒng)也是同樣適用的。

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：車載終端遠(yuǎn)程升級系統(tǒng)的設(shè)計與實現(xiàn)

本文網(wǎng)址：http://www.ezxoed.cn/html/support/11121513206.html