痞子衡嵌入式：飛思卡爾Kinetis系列MCU啟動那些事（10）- KBOOT特性(可靠升級)

　　大家好，我是痞子衡，是正經搞技術的痞子，今天痞子衡給大家介紹的是飛思卡爾Kinetis系列MCU的KBOOT之可靠升級（Reliable Update）特性，

　　所謂可靠升級機制，即在更新Application程序中不論發生任何例外情況（通信例外、系統斷電等）都能保證系統中至少有一份可用的Application用于恢復啟動，保證系統的正常運行，可靠升級是任何魯棒的Bootloader架構都應該要有的特性，作為一個健全的Bootloader架構，KBOOT中當然包含可靠升級特性，今天痞子衡就為大家介紹KBOOT中的Reliable Update特性：

一、可靠升級基本策略

　　可靠升級基本策略其實很簡單，在Flash里劃分2個區，主磁區用于存放待啟動的Application，備份區用于臨時存放新更新的Application，下載時永遠只往備份區存最新的Application，這樣即使下載程序中發生意外，也僅導致備份區里的Application不完整，不影響主磁區里的Application正常運行，僅當備份區里的Application經過Bootloader驗證是完整的（詳見痞子衡之前寫過的 《KBOOT特性(完整性檢測)》 一文，通過完整性檢測即認為Application是完整的），Bootloader才會啟動更新作業，將主磁區里Application擦除，然后將備份區里的Application拷貝到主磁區，最后擦除備份區里的Application，在這更新程序中不用擔心意外，因為任何時候Flash里都至少有一個Application是完整的，
　　KBOOT里的可靠升級特性就是按照上述基本策略實作的，但是我們知道KBOOT架構適用于上百種Kinetis芯片，上百種芯片特性各異，但就可靠升級這一特性而言，Kinetis芯片被分為三類：

• 第一類：不含ROM，且Flash沒有SWAP特性，如MKL25Z128
• 第二類：不含ROM，但Flash含有SWAP特性，如MK65FN2M
• 第三類：含ROM，無論Flash是否含有SWAP，如MKE18F512

　　KBOOT可靠升級在三類Kinetis芯片上的實作是有區別的，對于第一類，Flash起始地址存放固定的Bootloader，Main/Backup App緊隨其后，這也是最常見的情形；對于第二類，因為Flash有SWAP特性，所以Flash被嚴格分為兩個大小相等的Block，SWAP特性可以直接邏輯上交換這兩個Block，因此兩個Block除了各自存放Application之外還分別存放了Bootloader；對于第三類，這就比較簡單了，Bootloader在獨立的ROM區域，不占用Flash空間，因此Flash直接均分2等份，一份放Main App，另一份放Backup App就行，

二、可靠升級具體實作

　　上一節講過，根據Kinetis芯片Flash是否含有SWAP特性，可靠升級的實作是不同的，如果Flash有SWAP特性，我們稱之為硬可靠升級；反之，如果Flash不含SWAP特性，我們稱之為軟可靠升級，在介紹可靠升級具體實作邏輯之前，痞子衡先為大家比較一下軟/硬可靠升級的差異：

2.1 觸發方式

　　不管是硬可靠升級還是軟可靠升級都有兩種觸發方式，一種是上電啟動自觸發，上電Bootloader運行時會嘗試執行一次可靠升級，這種觸發方式是被動地且是一次性的；另一種是命令式觸發，即用戶通過blhost.exe發送reliable-update命令主動執行可靠升級，這種方式可重復多次，

2.1.1 命令式觸發

　　命令式觸發是觸發可靠升級操作的第一選擇，備份區下載完最新的Application后應緊跟著發送可靠升級命令完成新舊Application的更新，reliable-update命令格式在輸入blhost -?命令后可以看到：

　　reliable-update命令僅有一個addr引數，對于硬可靠升級，這個addr引數是swap indicator地址（想了解swap indicator的意義需要查看Kinetis手冊FTFx一節），如果是首次啟動硬可靠升級，swap indicator地址可任意設定，如果已經啟動過硬可靠升級，swap indicator已經存在芯片IFR里，此時addr必須與已存的swap indicator相一致；對于軟可靠升級，這個addr引數即備份區Application的存放起始地址（如果addr為0，則使用Bootloader里預定義的backup app存放地址），

2.1.2 上電自觸發

　　上電自觸發方式存在的原因是，用戶在備份區下載完Application之后可能會忘了主動觸發可靠升級，或者在執行主動可靠升級的程序中發生了例外，那么系統下一次啟動時應主動做一次可靠升級，確保將備份區最新的Application拷貝到主磁區去運行，下圖是自觸發可靠升級在Bootloader啟動流程中的位置：

2.2 主邏輯

　　無論是上電自觸發還是命令式觸發，在Bootloader里其實都是呼叫的如下函式bootloader_reliable_update_as_requested()，命令式觸發傳入的引數值是(kReliableUpdateOption_Swap, addr)，上電自觸發傳入的引數值是(kReliableUpdateOption_Normal, 0)

void bootloader_reliable_update_as_requested(reliable_update_option_t option, uint32_t address)
{
    uint32_t backupApplicationBase;
#if BL_IS_HARDWARE_SWAP_ENABLED
    // 僅對于硬可靠升級，才區分option引數的差異
    uint32_t swapIndicatorAddress = address;
    if (option == kReliableUpdateOption_Normal)
    {
	    // 檢測主磁區App是否有效，如果有效，則不進行可靠升級
        uint32_t mainApplicationBase = get_application_base(kSpecifiedApplicationType_Main);
        if (is_specified_application_valid(mainApplicationBase))
        {
            update_reliable_update_status(kStatus_ReliableUpdateStillInMainApplication);
            return;
        }
        else
        {
            // 檢測flash swap狀態看其是否處于Ready狀態，如果是，則從IFR里讀取已存swap indicator值
            status_t result = get_swap_indicator_address_if_system_is_in_ready(&swapIndicatorAddress);
            if (result != kStatus_FLASH_Success)
            {
                update_reliable_update_status(kStatus_ReliableUpdateSwapSystemNotReady);
                return;
            }
        }
    }
    backupApplicationBase = get_application_base(kSpecifiedApplicationType_Backup);
#else
    // 獲取備份區App的存放地址
    backupApplicationBase = (address == 0) ? get_application_base(kSpecifiedApplicationType_Backup) : address;
#endif // BL_IS_HARDWARE_SWAP_ENABLED

    // 檢測備份區App的BCA配置是否有效，BCA有效是進行可靠升級的前提
    if (!is_reliable_update_active(backupApplicationBase))
    {
        update_reliable_update_status(kStatus_ReliableUpdateInacive);
    }
    else
    {
        // 僅當備份區App通過了完整性檢測，才會進行可靠升級
        if (is_specified_application_valid(backupApplicationBase))
        {
#if BL_IS_HARDWARE_SWAP_ENABLED
            status_t status = hardware_reliable_update(swapIndicatorAddress);
#else
            status_t status = software_reliable_update(backupApplicationBase);
#endif // BL_IS_HARDWARE_SWAP_ENABLED
            update_reliable_update_status(status);
        }
        else
        {
            update_reliable_update_status(kStatus_ReliableUpdateBackupApplicationInvalid);
        }
    }
}

2.2.1 軟可靠升級流程

　　軟可靠升級流程如下，首先根據不同觸發方式獲取備份區App的存放地址，然后檢測備份區App是否合法（包含BCA，且通過完整性驗證），一旦備份區App被驗證是合法的，Bootloader會擦除主磁區App并將備份區App拷貝到主磁區，最后再擦除備份區App，有朋友會疑問，為何最后要擦除備份區App，因為當前的軟可靠升級實作在自觸發方式下第一件事就是去驗證備份區App是否有效，如果備份區App不擦除的話，每次上電都會做一次擦除和更新操作，會損耗Flash壽命，

　　上述流程就是KBOOT 2.0里的軟可靠升級的實作邏輯，那么這個流程有沒有改進空間呢？其實是有的，如果我們在App的BCA區域增加一個版本號，那么就可以做到在Flash里保留兩份App，此時Bootloader下載App時不再需要提供存放地址，Bootloader自動決議App的版本號，并用這個最新的App替換Flash里版本最低的App，而Bootloader啟動時永遠尋找當前Flash里版本最高的App去執行，

Note: 改進后的軟可靠升級有一個注意點，即Flash里XIP App并不是與位置無關的，因此兩份App的鏈接檔案根據存放位置不同，鏈接起始地址是不同的，

2.2.2 硬可靠升級流程

　　硬可靠升級相比軟可靠升級，在流程看起來更復雜，因為硬可靠升級涉及Flash的SWAP特性，不過硬可靠升級不具通用性，因此痞子衡不打算詳細解釋其流程，感興趣的自己研究下面的流圖，

2.3 配置宏和狀態碼

　　對于KBOOT 2.0來說，目前僅有MK65默認使能了可靠升級，如果想要在其他芯片上也使能這一特性，需要在對應芯片的bootloader_config.h里修改/增加如下三個宏：

• BL_FEATURE_RELIABLE_UPDATE: 設為1則使能可靠升級特性
• BL_FEATURE_HARDWARE_SWAP_UPDATE: 設為1則為硬可靠升級，0則為軟可靠升級
• BL_BACKUP_APP_START: 預定義的備份區App存放地址

　　在使用reliable-update命令的程序中會回傳執行結果狀態碼，以及可以用get-property獲得當前可靠升級狀態機的狀態，一共有如下8個狀態碼：

　　至此，飛思卡爾Kinetis系列MCU的KBOOT之可靠升級（Reliable Update）痞子衡便介紹完畢了，掌聲在哪里~~~

歡迎訂閱

文章會同時發布到我的 博客園主頁、CSDN主頁、微信公眾號 平臺上，

微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦，

標籤：嵌入式

上一篇：I2C協議學習筆記

下一篇：Arduino驅動ILI9341彩屏（一）——顏色問題