正文

大家好，周末好~今天為大家分享一款開源的，專為單片機(jī)開發(fā)的輕量級(jí) OTA 組件,挺有參考和學(xué)習(xí)意義的。

正文介紹部分：

一、簡(jiǎn)介

本開源工程是一款專為 32 位 MCU 開發(fā)的 OTA 組件，組件包含了bootloader、固件打包器(Firmware_Packager)、固件發(fā)送器三部分，并提供了一個(gè)基于 STM32F103 和 YModem-1K 協(xié)議的案例，因此本案例的固件發(fā)送器名為YModem_Sender。

mOTA 中的 m 可意為 mini 、 micro 、 MCU ( Microcontroller Unit )，而 OTA ( Over-the-Air Technology )，即空中下載技術(shù)，根據(jù)維基百科的定義， OTA 是一種為設(shè)備分發(fā)新軟件、配置，乃至更新加密密鑰（為例如移動(dòng)電話、數(shù)字視頻轉(zhuǎn)換盒或安全語(yǔ)音通信設(shè)備——加密的雙向無(wú)線電）的方法。OTA 的一項(xiàng)重要特征是，一個(gè)中心位置可以向所有用戶發(fā)送更新，其不能拒絕、破壞或改變?cè)摳?，并且該更新為立即?yīng)用到頻道上的每個(gè)人。用戶有可能“拒絕” OTA 更新，但頻道管理者也可以將其踢出頻道。由此可得出 OTA 技術(shù)幾個(gè)主要的特性：

1. 一個(gè)中心可向多個(gè)設(shè)備分發(fā)更新資料（固件）；

2. 更新資料一旦發(fā)送便不可被更改；

3. 設(shè)備可以拒絕更新；

4. 中心可以排除指定的設(shè)備，使其不會(huì)接收到更新資料。

本工程僅實(shí)現(xiàn) OTA 更新資料的部分技術(shù)，即上文列出的 OTA 技術(shù)幾個(gè)主要的特性，而不關(guān)心中心分發(fā)資料中間采用何種傳輸技術(shù)。（本工程的 example 使用 UART 作為 MCU 和外部的傳輸媒介）

?

二、實(shí)現(xiàn)的功能

MCU 設(shè)備上的 OTA 升級(jí)可理解為 IAP (In Application Programming) 技術(shù)， MCU 通過(guò)外設(shè)接口（如 UART 、 IIC 、 SPI 、 CAN 、 USB 等接口），連接具備聯(lián)網(wǎng)能力的模塊、器件、設(shè)備（以下統(tǒng)稱上位機(jī)）。上位機(jī)從服務(wù)器上拉取固件包，再將固件包以約定的通訊協(xié)議，經(jīng)由通訊接口發(fā)送至 MCU ，由 MCU 負(fù)責(zé)固件的解析、解密、存儲(chǔ)、更新等操作，以完成設(shè)備固件更新的功能。需要注意的是，example提供的示例不基于文件系統(tǒng)，而是通過(guò)對(duì) Flash 劃分為不同的功能區(qū)域完成固件的更新。

本組件實(shí)現(xiàn)了以下功能：

1. 固件包完整性檢查：自動(dòng)檢測(cè)固件 CRC 值，保證固件數(shù)據(jù)的可靠性。

2. 固件加密：支持 AES256 加密算法，提高固件的安全性。

3. APP 完整性檢查：支持 APP 運(yùn)行前進(jìn)行完整性檢查，以確認(rèn)運(yùn)行的固件無(wú)數(shù)據(jù)缺陷。

4. 斷電保護(hù)：當(dāng)固件更新過(guò)程中（含下載、解密、更新等過(guò)程），任何一個(gè)環(huán)節(jié)斷電，設(shè)備再次上電時(shí)，依然能確保有可用的固件。（需配置為至少雙分區(qū)）

5. 固件水印檢查：可檢測(cè)固件包是否攜帶了特殊的水印，確認(rèn)非第三方或非匹配的固件包。

6. 固件自動(dòng)更新：當(dāng) download 或 factory 分區(qū)有可用的固件，且 APP 分區(qū)為空或 APP 分區(qū)不是最新版本的固件時(shí)，可配置為自動(dòng)開始更新。

7. 恢復(fù)出廠設(shè)置：factory 分區(qū)存放穩(wěn)定版的固件，當(dāng)設(shè)備需要恢復(fù)出廠設(shè)置時(shí)，該固件會(huì)被更新至 APP 分區(qū)。

8. 無(wú)須 deinit ：我們知道，固件更新完畢后從 bootloader 跳轉(zhuǎn)至 APP 前需要對(duì)所用的外設(shè)進(jìn)行 deinit ，恢復(fù)至上電時(shí)的初始狀態(tài)。本組件的 bootloader 包含了下載器的功能，當(dāng)使用復(fù)雜的外設(shè)收取固件包時(shí)， deinit 也將變得復(fù)雜，甚至很難排除對(duì) APP 的影響。為此，本組件采用了再入 bootloader 的方式，給 APP 提供一個(gè)相當(dāng)于剛上電的外設(shè)環(huán)境，免去了 deinit 的代碼。

9. 功能可裁剪：本組件通過(guò)功能裁剪可實(shí)現(xiàn)單分區(qū)、雙分區(qū)、三分區(qū)的方案切換、是否配置解密組件、是否自動(dòng)更新 APP 、是否檢查 APP 完整性、是否使用 SPI Flash （待實(shí)現(xiàn)）。

10. 固件存放至 SPI flash ：本組件可通過(guò)user_config.h配置 download 分區(qū)和 factory 分區(qū)的所在位置為片內(nèi) flash 或 SPI flash ，使用了 SFUD (Serial Flash Universal Driver)作為 SPI flash 的底層驅(qū)動(dòng)庫(kù)。若使用的 SPI flash 支持 SFDP (Serial Flash Discovable Parameters)，則可在不修改任何源代碼的情況下更換其它品牌型號(hào)的 SPI flash 。若不支持 SFDP ，SFUD 中已有對(duì)應(yīng) SPI flash 參數(shù)表的話，也可做到在不修改任何源代碼的情況下更換其它品牌型號(hào)的 SPI flash 。

?

三、 bootloader 架構(gòu)

（一）軟件架構(gòu)

• 硬件層描述的是運(yùn)算器件和邏輯器件，如CPU、ADC、TIMER、各類IC等，是所有軟件組件的硬件基礎(chǔ)，是軟件邏輯的最終底層實(shí)現(xiàn)。

• 硬件抽象層是位于驅(qū)動(dòng)與硬件電路之間的接口層，將硬件抽象化。它隱藏了特定平臺(tái)的硬件接口細(xì)節(jié)，為驅(qū)動(dòng)層提供抽象化的硬件接口，使其具有硬件無(wú)關(guān)性。

• 驅(qū)動(dòng)層通過(guò)調(diào)用硬件抽象層的開放接口，實(shí)現(xiàn)一定的邏輯功能后封裝，提供給上層軟件調(diào)用。

• 數(shù)據(jù)傳輸層負(fù)責(zé)收發(fā)數(shù)據(jù)，對(duì)外開放的是數(shù)據(jù)發(fā)送與接收相關(guān)的接口，屏蔽了通訊接口的邏輯代碼，使其易于修改為其他類型的通訊接口。

• 協(xié)議析構(gòu)層將調(diào)用數(shù)據(jù)傳輸層的數(shù)據(jù)收發(fā)接口進(jìn)行封包發(fā)送與收包解析，通過(guò)實(shí)現(xiàn)用戶的自定義協(xié)議，完成對(duì)數(shù)據(jù)的構(gòu)造和解析。

• 應(yīng)用層負(fù)責(zé)業(yè)務(wù)邏輯代碼的實(shí)現(xiàn)，通過(guò)調(diào)用其他層封裝的接口，完成頂層邏輯功能。

?

（二）文件架構(gòu)

?

四、 bootloader 的設(shè)計(jì)思路

整個(gè) bootloader 設(shè)計(jì)思路的內(nèi)容較多，本設(shè)計(jì)思路也以 PDF 文檔的形式提供，詳見(jiàn)《bootloader程序設(shè)計(jì)思路》。

?

五、固件更新流程

根據(jù)配置的分區(qū)方案不同，固件的更新流程會(huì)有些不同，此處僅展示簡(jiǎn)要的更新流程，便于快速理解固件更新的流程，因此屏蔽了很多細(xì)節(jié)，更詳細(xì)的內(nèi)容，請(qǐng)閱讀《bootloader程序設(shè)計(jì)思路》文檔和源代碼。

本組件的目的是最大程序的減少 APP 的改動(dòng)量以實(shí)現(xiàn) OTA 的功能，從下圖可知， bootloader 便完成了固件的下載、存放、校驗(yàn)、解密、更新等所有操作， APP 部分所需要做的有以下三件事。

1. 根據(jù) bootloader 占用的大小和 flash 的最小擦除單位，重新設(shè)置 APP 的起始位置和中斷向量表。

2. 增加觸發(fā)進(jìn)入 bootloader 以開始固件更新的方式。（如：接收來(lái)自上位機(jī)的更新指令）

3. 設(shè)置一個(gè)更新標(biāo)志位，且這個(gè)標(biāo)志位在 APP 軟復(fù)位進(jìn)入 bootloader 時(shí)仍能被讀取到。（當(dāng)固件更新的方式為上位機(jī)指令控制時(shí)，可以不執(zhí)行此步驟）

??一般來(lái)說(shuō)，通知 bootloader 需要進(jìn)行固件更新的方式有以下兩種：

1. 采用上位機(jī)指令控制的方式，優(yōu)點(diǎn)是 APP 無(wú)須設(shè)置更新標(biāo)志位，即便設(shè)備在收到更新指令后斷電，也可以照常更新。缺點(diǎn)是設(shè)備在上電后， bootloader 需要等待幾秒的時(shí)間（時(shí)間長(zhǎng)短由通訊協(xié)議和上位機(jī)決定），以確認(rèn)是否有來(lái)自上位機(jī)的更新指令，從而決定進(jìn)入固件更新模式亦或跳轉(zhuǎn)至 APP 。

2. APP 在軟復(fù)位進(jìn)入 bootloader 之前設(shè)置一個(gè)特殊的標(biāo)志位，可以放置在 RAM 、備份寄存器或者外部的非易失性存儲(chǔ)介質(zhì)中（如：EEPROM）。此方式的優(yōu)點(diǎn)是設(shè)備上電時(shí) bootloader 無(wú)須等待和驗(yàn)證是否有固件更新的指令，通過(guò)標(biāo)志位便可決定是否進(jìn)入固件更新模式亦或跳轉(zhuǎn)至 APP ，且利用再入 bootloader 的機(jī)制，可以給 APP 提供一個(gè)干凈的外設(shè)環(huán)境。缺點(diǎn)則是 APP 和 bootloader 都要記錄標(biāo)志位所在的地址空間，且該地址空間不能被挪作他用，不能被意外修改，更不能被編譯器初始化。相較于上個(gè)方案多了要專門指定該變量的地址并且不被初始化的步驟。若使用的是 RAM 作為記錄標(biāo)志位的介質(zhì)，則還有斷電后更新標(biāo)志信息丟失的問(wèn)題。

綜上所述，沒(méi)有完美的方案。本組件支持上述方案二選一，根據(jù)實(shí)際需求進(jìn)行選擇和取舍即可。

由于案例采用了 YModem-1K 協(xié)議，而本組件開始固件更新的方式是通過(guò)上位機(jī)發(fā)送指令開始的，因此測(cè)試時(shí)若設(shè)備正在運(yùn)行 APP ，需要有個(gè)進(jìn)入 bootloader 的條件，為了便于展示，案例使用了板卡上的功能按鍵作為觸發(fā)條件，模擬上位機(jī)向設(shè)備發(fā)送了更新指令，詳見(jiàn)案例的使用說(shuō)明。

?

六、固件檢測(cè)與處理機(jī)制

之所以單獨(dú)列出固件的檢測(cè)與處理機(jī)制，是為了方便理解代碼邏輯，此部分也以 PDF 文檔的形式提供，詳見(jiàn)《固件檢測(cè)與處理機(jī)制》。

?

七、所需的工具

1. Firmware_Packager 此工具是必選項(xiàng)，負(fù)責(zé)打包 bin 固件，并為 bin 固件添加一個(gè) 96 byte 的表頭，最終生成為 fpk(Firmware Package) 固件包。關(guān)于 96 byte 表頭的具體內(nèi)容，詳見(jiàn)《fpk固件包表頭信息》。由于 YModem-1K 協(xié)議的每包的數(shù)據(jù)大小是 1 Kbyte ，為了便于 bootloader 解包，本工具也將固件表頭擴(kuò)大至了 1 Kbyte ，若自定義的協(xié)議支持可變包長(zhǎng)，可將表頭長(zhǎng)度恢復(fù)為 96 byte 。

需要注意的是，本案例選擇了 YModem-1K 協(xié)議，因此若直接采用或測(cè)試example目錄中的案例，固件打包器的表頭尺寸需要選擇 1024 byte 。

2. YModem_Sender 本工程的 example 采用廣泛使用且公開的 YModem-1K 通訊協(xié)議，因此也提供了一個(gè)基于 YModem-1K 協(xié)議的發(fā)送器。由于固件發(fā)送器和通訊協(xié)議是綁定的，實(shí)際使用時(shí)，不必綁定此工具，本工程僅為了方便測(cè)試而提供。

注：以上的工具是基于 Qt6 開發(fā)的，YModem_Sender 依賴 Qt 的 serial_port 庫(kù)，需要自行添加。以上工具作為 OTA 組件的一部分，自然也是開源的。運(yùn)行平臺(tái)是 windows ，目前僅在 win10 和 win11 上測(cè)試過(guò)。若需要修改和編譯工程，需要自行安裝 Qt ，請(qǐng)自行搜索安裝教程。

?

八、組件占用的空間

本組件的案例是基于 YModem-1K 協(xié)議及 UART 作為 MCU 與外部的數(shù)據(jù)傳輸媒介，因此不是僅計(jì)算核心代碼部分的占用空間情況，而是整個(gè)可用工程。此數(shù)據(jù)才更有參考意義。以下是幾種方案配置占用的 flash 和 RAM 的大小。

1. 最小占用（單分區(qū) ）
   Program Size: Code=7796 RO-data=464 RW-data=116 ZI-data=9316
   flash: 8376 byte (8.18 kB)
   ram: 9432 byte (9.21 kB)

2. 一般占用（單分區(qū) + 解密組件）
   Program Size: Code=8574 RO-data=1010 RW-data=116 ZI-data=9572
   flash: 9700 byte (9.47 kB)
   ram: 9688 byte (9.46 kB)

3. 一般占用（三分區(qū) ）
   Program Size: Code=8846 RO-data=614 RW-data=116 ZI-data=9348
   flash: 9576 byte (9.35 kB)
   ram: 9464 byte (9.24 kB)

4. 最大占用（三分區(qū) + 解密組件）
   Program Size: Code=9706 RO-data=1158 RW-data=116 ZI-data=9604
   flash: 10980 byte (10.72 kB)
   ram: 9720 byte (9.49 kB)

因雙分區(qū)和三分區(qū)的占用尺寸相差較小，因此不單獨(dú)列出雙分區(qū)的占用情況。本組件已盡量壓縮尺寸，但由于固件數(shù)據(jù)的處理需要一定的 RAM 開銷，此部分除非修改每個(gè)分包的最小處理單位（目前是 4096 byte ），否則已經(jīng)很難進(jìn)一步壓縮，請(qǐng)按實(shí)際需求選擇。

?

九、移植說(shuō)明

由于寫教程工作量較大，本開源工程暫不提供詳細(xì)的移植說(shuō)明文檔。代碼已分層設(shè)計(jì)，具備一定的移植性，有經(jīng)驗(yàn)的工程師看example中的示例代碼和本說(shuō)明基本都能自行移植到別的芯片平臺(tái)。這里僅做幾點(diǎn)說(shuō)明。

挖個(gè)坑，后續(xù)有時(shí)間再錄個(gè)移植視頻。

1. bootloader 部分的核心代碼都在source目錄下，是移植的必需文件。

2. source/Component和source/BSP目錄下的組件庫(kù)非移植的必選項(xiàng)，根據(jù)功能需要進(jìn)行裁剪。

3. 因固件包含表頭，固件寫入的 flash 分區(qū)的方式與通訊協(xié)議是強(qiáng)相關(guān)的。若自定義的協(xié)議支持可變長(zhǎng)度，那么建議傳輸?shù)谝粋€(gè)分包時(shí)就是固件表頭的大小（標(biāo)準(zhǔn)表頭大小是 96 byte ，本工程因采用 YModem-1K 協(xié)議，固件打包器將表頭擴(kuò)大到了 1 Kbyte，自行修改即可），從而方便 bootloader 解包。

4. 除開表頭部分，固件的每個(gè)切包不能超過(guò) 4096 byte ，且 4096 除以每個(gè)切包大小后必須是整數(shù)（如常見(jiàn)的128、256、512、1024、2048等），否則就得修改源碼。

5. 單分區(qū)方案雖然節(jié)省了 flash 空間，但本組件的很多功能和安全特性都無(wú)法使用，除非 flash 實(shí)在受限，否則建議至少使用雙分區(qū)的方案。

??以下是移植的基本步驟

（一）bootloader 部分

建議參考example中的案例進(jìn)行移植。

1. 創(chuàng)建一個(gè)代碼工程，并確保這個(gè)工程可以正常運(yùn)行。（如：控制一個(gè) LED 閃爍）

2. 將source目錄下的文件放到工程目錄下，可隨意放置和命名。

3. 將source目錄下的文件按需添加進(jìn)代碼工程中（source/Component目錄下的組件庫(kù)非移植的必選項(xiàng)），并包含對(duì)應(yīng)的頭文件目錄。

4. 實(shí)現(xiàn)data_transfer_port.c和fal_stm32f1_flash.c內(nèi)的函數(shù)，若與案例一致，則無(wú)需修改。

5. 若使用了自定義的通訊協(xié)議，則修改protocol_parser.c和protocol_parser.h，若與案例一致，則無(wú)需修改。

6. 將app.c文件內(nèi)的函數(shù)移植進(jìn)你的應(yīng)用代碼，記得包含app.h，必要時(shí)可修改。

7. 嘗試編譯并解決編譯器報(bào)錯(cuò)的問(wèn)題。（若提示缺失部分文件，可在example目錄中尋找并添加進(jìn)工程，后續(xù)再行修改也是可以的 ）

8. 按需求設(shè)置好user_config.h文件，請(qǐng)仔細(xì)閱讀說(shuō)明。

9. 查看app_config.h是否有需要修改的配置項(xiàng)。

10. 若選擇了“使用標(biāo)志位作為固件更新的依據(jù)USING_APP_SET_FLAG_UPDATE”（否則忽略此步驟），且標(biāo)志位放置在 RAM ，則需要配置標(biāo)志位update_flag所在的 RAM 地址，并且配置 IDE 或分散加載文件不對(duì)其進(jìn)行初始化。IDE 配置的方式參考如下圖所示。（ 需包含common.h） 其中，宏FIRMWARE_UPDATE_VAR_ADDR在user_config.h中配置，本案例是0x20000000。注意，提供給update_flag的 RAM 區(qū)域一定要勾選NoInit。

/* 固件更新的標(biāo)志位，該標(biāo)志位不能被清零 */
#if (USING_IS_NEED_UPDATE_PROJECT == USING_APP_SET_FLAG_UPDATE)
    #if defined(__IS_COMPILER_ARM_COMPILER_5__)
    volatile uint64_t update_flag __attribute__((at(FIRMWARE_UPDATE_VAR_ADDR), zero_init));

    #elif defined(__IS_COMPILER_ARM_COMPILER_6__)
        #define __INT_TO_STR(x)     #x
        #define INT_TO_STR(x)       __INT_TO_STR(x)
        volatile uint64_t update_flag __attribute__((section(".bss.ARM.__at_" INT_TO_STR(FIRMWARE_UPDATE_VAR_ADDR))));

    #else
        #error "variable placement not supported for this compiler."
    #endif
#endif

?

11. 工程配置建議選擇 AC6 （雖然本組件也支持 AC5 ，除非不得已，否則建議使用 AC6），選擇C99（如果使用了perf_counter，則需要選擇gnu99） ，優(yōu)化根據(jù)需要選擇即可，建議按下圖所示配置。

12. 嘗試再次編譯并解決編譯器提示的問(wèn)題。

13. 若選擇了“使用標(biāo)志位作為固件更新的依據(jù)USING_APP_SET_FLAG_UPDATE”（否則忽略此步驟），編譯通過(guò)后，查看 map 文件是否新增了一個(gè) Region ，并且地址正確，Type為Zero，該區(qū)域?yàn)?/span>UNINIT，若全部符合，則移植成功。

（二）APP 部分

APP 部分的移植相對(duì)簡(jiǎn)單，可直接參考example中的案例。

1. 創(chuàng)建一個(gè)代碼工程，并確保這個(gè)工程可以正常運(yùn)行。（如：控制一個(gè) LED 閃爍）

2. 確定 APP 在 flash 中的地址，需考慮 bootloader 的大小（不能和 bootloader 有沖突），中斷向量表對(duì)地址的要求（如必須是 0x200 的整數(shù)倍）， flash 的擦除粒度（因 flash 擦除時(shí)是以扇區(qū)為單位的）。需要注意的是， APP 的地址一定要和 bootloader 的user_config.h中配置的一致，否則無(wú)法運(yùn)行。

3. 在外設(shè)初始化前修改中斷向量表， keil 可采用下圖的方式修改，一勞永逸。

/* 設(shè)置中斷向量表后，開啟總中斷 */
extern int Image$$ER_IROM1$$Base;
BSP_INT_DIS();
SCB->VTOR = (uint32_t)&Image$$ER_IROM1$$Base;
BSP_INT_EN();

?

4. 同 bootloader 部分的步驟 10 一致。

5. 增加固件更新時(shí)進(jìn)入 bootloader 的代碼，如上位機(jī)發(fā)送固件更新的指令。（測(cè)試時(shí)可通過(guò)按鍵模擬上位機(jī)發(fā)送固件更新）

6. 在執(zhí)行固件更新的指令的代碼處，添加設(shè)置update_flag標(biāo)志位的值和系統(tǒng)復(fù)位的代碼，如下圖所示。其中，FIRMWARE_UPDATE_MAGIC_WORD的值是0xA5A5A5A5，注意此值要和 bootloader 保持一致 。
   若需要通過(guò)標(biāo)志位使用“恢復(fù)出廠固件”的功能，也是同理，對(duì)應(yīng)的宏則是FIRMWARE_RECOVERY_MAGIC_WORD，值為0x5A5A5A5A。

update_flag = FIRMWARE_UPDATE_MAGIC_WORD;
HAL_NVIC_SystemReset();

7. 嘗試再次編譯并解決編譯器提示的問(wèn)題。

8. 同 bootloader 部分的步驟 13 一致。

?

十、一些問(wèn)題的解答

1. 為什么不使用 RTOS ？

為了最大程度的減少 bootloader 占用的 flash 空間，體積越小，組件的適用范圍就越廣。當(dāng)然，本組件是開源的，想在 bootloader 里增加 RTOS 或者其它代碼也是可以的。

?

2. 為什么要將 bootloader 設(shè)計(jì)在 flash 的首地址？

我們知道， bootloader 的運(yùn)行環(huán)境最理想的情況是未經(jīng)使用任何外設(shè)的。有些設(shè)計(jì)會(huì)將 APP 放置在 flash 首地址， bootloader 放置在其它地址，優(yōu)點(diǎn)是 APP 無(wú)須設(shè)置 APP 的起始位置和中斷向量表，改動(dòng)量最少，缺點(diǎn)是這種方式很難做到通用，需要在 bootloader 或 APP 中 deinit 所使用的外設(shè)，否則固件更新時(shí)可能會(huì)出現(xiàn)各式各樣的異常。實(shí)際上，每個(gè)設(shè)備每個(gè)產(chǎn)品所使用的外設(shè)都是不確定的，為了做到通用，本組件選擇了 bootloader 設(shè)計(jì)在 flash 的首地址的方案。

?

3. 為什么要設(shè)計(jì)成單分區(qū)、雙分區(qū)和三分區(qū)？

現(xiàn)實(shí)情況是，并非所有設(shè)備的 flash 空間都有比較大的富余。有些設(shè)備，無(wú)法使用多個(gè)分區(qū)， bootloader + APP 分區(qū)已經(jīng)是極限。而 bootloader 分區(qū)方案不同時(shí)，其占用的 flash 大小也不同，為了盡可能的減小 bootloader 的體積，而將分區(qū)設(shè)計(jì)成可配置的方式。

?

4. 什么是 fpk ？

fpk 是 mOTA 組件的固件打包器生成的一種文件，基于 bin 文件，在其頭部增加了一個(gè) 96 byte 表頭后合成的一個(gè)新文件，后綴是.fpk。fpk 取自英文詞語(yǔ) Firmware Package 的縮寫，意為固件程序包，本組件統(tǒng)稱為固件包，而提及固件時(shí)，一般指的是 bin 文件。

?

5. 我可以不用固件打包器（Firmware_Packager），直接用 bin 文件進(jìn)行更新嗎？

目前是不能的。本組件提供的功能和安全特性是基于 fpk 表頭和多分區(qū)的方式實(shí)現(xiàn)的，因此需要固件打包器打包固件，生成 fpk 固件包。為了最大程度的使用這些功能和安全特性， bootloader 的更新流程是基于含有表頭的固件包開發(fā)的，暫時(shí)不考慮增加不含表頭的更新流程。當(dāng)然，不排除因?yàn)橐蟮娜硕嗔?，我就開搞了。

?

十一、引用的第三方庫(kù)

??本開源工程使用了或?qū)⑹褂靡韵碌牡谌綆?kù)，感謝以下優(yōu)秀的代碼庫(kù)（排名不分先后）。

1. fal(Flash Abstraction Layer) ，RT-Thread 團(tuán)隊(duì)的開發(fā)的庫(kù)，是對(duì) Flash 及基于 Flash 的分區(qū)進(jìn)行管理、操作的抽象庫(kù)。

2. SFUD(Serial Flash Universal Driver) 一款使用 JEDEC SFDP 標(biāo)準(zhǔn)的串行 (SPI) Flash 通用驅(qū)動(dòng)庫(kù)。

3. crc-lib-c為本工程的 CRC32 驗(yàn)算提供了基礎(chǔ)。

4. tinyAES這是一個(gè)用 C 編寫的 AES 、 ECB 、 CTR 和 CBC 加密算法的小型可移植的庫(kù)。

5. SEGGER RTTSEGGER's Real Time Transfer (RTT) is the proven technology for system monitoring and interactive user I/O in embedded applications. It combines the advantages of SWO and semihosting at very high performance.

6. perf_counter該庫(kù)利用 SysTick 實(shí)現(xiàn)了代碼的運(yùn)行時(shí)間測(cè)量和通用的 ms 及 us 的延時(shí)函數(shù)，且不影響原有的 SysTick 功能和邏輯，若使用的是 AC5 或 AC6 ，可以做到無(wú)感使用，即只需將 perf_counter 庫(kù)添加進(jìn)代碼工程后即可直接使用，無(wú)需調(diào)用 init 之類的任何函數(shù)。