CH592接wifi模塊，通過串口ota，升級參考OTA例程BackupUpgrade_OTA，IAP擦寫校驗新固件成功后，卡在jumpApp()這里，無法正常啟動app。

1、編譯生成的固件包app.bin，通過BackupUpgrade_OTA例程可以正常升級啟動，固件包應(yīng)該沒有問題。

2、串口數(shù)據(jù)接收后，通過了MD5校驗，沒有丟幀，F(xiàn)LASH_ROM_VERIFY也正常通過。

3、四個分區(qū)地址也跟demo保持一致。

請教下app啟動異常的原因可能有哪些，怎么排查。

app的地址分配

“卡在jumpApp()這里，無法正常啟動app”

執(zhí)行jumpAPP()后會怎樣，會復(fù)位嗎，還是串口打印日志不再繼續(xù)運行了？

IAP層代碼是基于哪個工程修改的，如果是基于UART1歷程修改的，注意.s文件中要配置更高的權(quán)限（.s文件倒數(shù)幾行，有一處原0x88，需要改為0x1888）；如果是基于BLEOTA的IAP層代碼修改的，那此處默認配置好了。

執(zhí)行jumpAPP()后一直復(fù)位，IAP層代碼是基于BLEOTA的IAP層代碼修改的，默認配置。

這是我擦寫imageB 分區(qū)的代碼，是否有問題呢。麻煩大佬幫忙看下

void?earse_imageB()
{
????OpAdd?=?0;
????uint32_t?op;
????while(1)
????{
????????op?=?FLASH_ROM_ERASE(IMAGE_B_START_ADD?+?OpAdd,?FLASH_BLOCK_SIZE);
????????if(op)
????????{
????????????App_Printf("Ota?E?fail?%08x\n",?IMAGE_B_START_ADD?+?OpAdd);
????????????continue;
????????}
????????OpAdd?+=?FLASH_BLOCK_SIZE;
????????if(OpAdd?>=?IMAGE_B_SIZE)
????????{
????????????App_Printf("Ota?E?succ\n");

????????????OpAdd?=?0;
????????????break;
????????}
????}
}

void?OTA_write_imageB(unsigned?char?*data?,UINT32?datalen)
{
????uint32_t?op?=?0;
????UINT32?write_len=datalen;
????UINT32?data_offset=0;
????UINT8?OTA_DATA[1025]={0};
????memcpy(OTA_DATA,data,write_len);
????while(write_len)
????{
????????if(write_len>128)
????????{
????????????op?=?FLASH_ROM_WRITE(IMAGE_B_START_ADD?+?OpAdd,OTA_DATA+data_offset,?128);
????????????op?|=?FLASH_ROM_VERIFY(IMAGE_B_START_ADD?+?OpAdd,OTA_DATA+data_offset,?128);
????????????if(!op)
????????????{
????????????????App_Printf("Ota?W?success?%08x?,OpAdd=%d?,data_offset=%d\n",?IMAGE_B_START_ADD?+?OpAdd,?OpAdd,data_offset);
????????????????OpAdd?+=?128;????????????
????????????}
????????????else?{
????????????????App_Printf("Ota?W?fail?%08x?%d\n",?IMAGE_B_START_ADD?+?OpAdd,?OpAdd);
????????????}
????????}
????????else?{
????????????op?=?FLASH_ROM_WRITE(IMAGE_B_START_ADD?+?OpAdd,OTA_DATA+data_offset,?write_len);
????????????op?|=?FLASH_ROM_VERIFY(IMAGE_B_START_ADD?+?OpAdd,OTA_DATA+data_offset,?write_len);
????????????if(!op)
????????????{
????????????????App_Printf("Ota?W?success?%08x?,OpAdd=%d?,data_offset=%d\n",?IMAGE_B_START_ADD?+?OpAdd,?OpAdd,data_offset);
????????????????OpAdd?+=?write_len;

????????????????if(OpAdd?==?OTA_total_len)?{
????????????????????App_Printf("Ota?to?B?complete?\n");
????????????????????if(MD5_check_ok?==?1)
????????????????????{
????????????????????????App_Printf("Ota?start...\n");
????????????????????????SYS_DisableAllIrq(NULL);
????????????????????????SwitchImageFlag(IMAGE_IAP_FLAG);
????????????????????????while(1)
????????????????????????????SYS_ResetExecute();
????????????????????}
????????????????????else?{
????????????????????????App_Printf("Ota?Cksum?fail\n");
????????????????????}

????????????????}
????????????}
????????????else?{
????????????????App_Printf("Ota?W?fail?%08x?%d\n",?IMAGE_B_START_ADD?+?OpAdd,?OpAdd);
????????????}
????????????write_len=-1;
????????????break;

????????}
????????write_len=write_len-128;
????????data_offset=data_offset+128;
????}

}

UART接收新固件的代碼，基于BLE的OTA方案中的IAP例程修改，那么.s和.ld文件可以不改。
有沒有在IAP中添加串口中斷？
如果添加了中斷功能（無論添加了何種中斷都要處理，以最可能用到的串口中斷為例），在跳轉(zhuǎn)到APP層代碼前，要將串口中斷關(guān)閉，否則在APP層代碼中一旦啟用同一個串口中斷，但找不到中斷服務(wù)函數(shù)入口，會導(dǎo)致MCU不斷復(fù)位。

IAP使用的就是demo的代碼，沒有做修改，也沒有添加中斷。

IAP代碼完全沒有改動，“四個分區(qū)地址也跟demo保持一致”，那IAP層代碼應(yīng)該沒問題?！?span style="color:rgb(51,51,51);">通過BackupUpgrade_OTA例程可以正常升級啟動”那APP層代碼本身是可以工作?？赡茉诠碳D(zhuǎn)發(fā)環(huán)節(jié)中出了問題。

“編譯生成的固件包app.bin”

升級使用的APP層代碼的bin文件，①是MRS編譯器直接生成的，②還是使用hex轉(zhuǎn)bin工具轉(zhuǎn)換而來的？

①方式中，bin文件從頭開始即存放APP層代碼。

②方式中，bin文件可能會填充前4K內(nèi)容，從4K開始存放APP層代碼。

OTA升級方案中，手機APP會截掉bin文件的前4K內(nèi)容再下發(fā)給MCU，要用②方式中填充頭部內(nèi)容的bin文件來做升級。

①②方式下生成的bin文件可以都拿來升級試試看，或者看看WIFI模塊收到的bin，是不是從APP層代碼的起始位置開始下發(fā)的。

MRS編譯器直接生成bin文件的方式：MRS CH573 CH582生成BIN文件 - debugdabiaoge - 博客園

若仍有異常，可以郵件聯(lián)系溝通更多細節(jié) zhaiyw@wch.cn

確實是hex轉(zhuǎn)bin的時候，填充了前4K的內(nèi)容，截掉這4K可以正常升級了，感謝大佬的支持。