之前沒有接觸過wch藍(lán)牙，參考相關(guān)例程，升級(jí)都是直接使用合并的文件。那么592是如何確保升級(jí)文件安全性？
還是說bl層已經(jīng)實(shí)現(xiàn)了，使用合并工具就行？用戶無需處理？

藍(lán)牙傳輸本身是可靠傳輸，在進(jìn)行升級(jí)的時(shí)候會(huì)有主機(jī)（手機(jī)APP）傳輸數(shù)據(jù)給從機(jī)后，再進(jìn)行校驗(yàn)的操作，確保從機(jī)接收到數(shù)據(jù)。

目前提供的例程，前面4K是作為跳轉(zhuǎn)，緊跟著是APP區(qū)域。ISP工具在燒錄的時(shí)候一定會(huì)擦除前8K，如果被讀取代碼也一定會(huì)丟失APP的前4K代碼，不會(huì)讀取到完整的。

基于例程的藍(lán)牙OTA升級(jí)，框架已經(jīng)搭建好，用戶只需要管理用戶代碼即可。

我想表達(dá)的是分發(fā)文件的安全性，比如客戶程序需要分發(fā)給第三方app開發(fā)者做測試，在終端也存在升級(jí)文件被抓包的可能性，針對該部分是否有效？以前做過的都是單獨(dú)生成的升級(jí)文件，并沒有提供過直接編譯生成的文件。所以沒弄明白是如何保護(hù)的。感謝回復(fù)。

1、藍(lán)牙OTA升級(jí)的空中數(shù)據(jù)，可以被抓包工具抓取到。但是抓取到的是原始數(shù)據(jù)，需要進(jìn)一步解析。如抓包到0x01，但是無法知道0x01代表何種意義，即使抓取到也無意義。例程接收到數(shù)據(jù)后會(huì)根據(jù)IAP的協(xié)議進(jìn)行解析。此部分具體協(xié)議可以自己定義或者基于例程的基礎(chǔ)上再添加校驗(yàn)進(jìn)一步保險(xiǎn)；

2、終端用戶需要升級(jí)的時(shí)候，可以提供bin文件，用戶自行進(jìn)行升級(jí)?；蛘咧苯犹峁┛蛻鬉PP，同時(shí)APP里面包含bin文件，終端用戶則不會(huì)直接接觸到待升級(jí)的文件 ，這樣也增加了文件的安全性；

3、如果需要尋找第三方開發(fā)APP同時(shí)擔(dān)心他們開發(fā)的時(shí)候盜取你的文件，可以在APP代碼進(jìn)行加密，iap接收數(shù)據(jù)的時(shí)候再進(jìn)行解密并填寫FLASH升級(jí)。使用第三方APP的時(shí)候只管透傳，無法解析到你的用戶代碼。