一共4个 hex 文件. JUMP IAP APP BLE_ROM
在MounRiver中编译完成后,显示文件大小都在范围内.
将4个HEX文件进行 合并.
合并后得到 443k 的all.bin文件.
使用 WCHISPStudio 下载该bin文件.机器无法运行.
如果使用 WCHISPStudio 同时下载这4个hex文件. 机器可正常运行
离线烧录器需要使用 all.bin 文件. 用离线烧录器和 WCHISPStudio 下载文件后,机器都无法启动.
请帮忙分析一下
用合成工具合成之后烧录和用isp工具同时下载四个hex是一样的，我看你的OTA程序做出来一些变动，可以用例程包里的OTA例程合成烧录测试是否能够正常运行。
我不方便去测试demo中的IAP程序, demo的固定地址是 0X10000 .
我的工程中使用的是 0x50000
jump , IAP , APP , BLE_ROMx .
这4个文件应该都是正常的.
我一直都是使用 WCHISPStudio 同时下载4个hex文件进行开发的.
马上准备要生产了, 需要使用离线烧录器,才把4个文件进行合并.
合并后就出现了 上述的异常.
合并工具中的 BinFileSize 是表示对应hex转为bin后的大小吗. 看起来有点不对呀.
我可以把这4个 hex 发你.
你给我个邮箱吧.
IAP程序, 只是在 OTA的demo基础上,
加了几个io控制下指示灯 和 一个按键重启.
让你使用demo测试是为了验证使用合成软件合成bin烧录也是可以正常运行的，
合并工具中的BINFileSize减去起始地址大小就是BIN的实际大小，
方便的话可以把完整工程发送至邮箱个人信息保护，已隐藏。
573的
合并工具.rar 582同理去生产下a.hex和b.hex
mergehex.exe -m a.hex b.hex 真正运行的程序.hex -o out.hex 使用bat脚本合并的文件，a b 就是分别BOOT 跳转和判断分区标志烧录如果是官方默认
/* 整个用户code区分成四块，4K，216K，216K，12K，后三块下面分别叫做imageA（用户代码区），imageB（备份代码区）和imageIAP */
的标志，只要再运行的程序进行写IMAGEB 然后写入标志，开机自己会去把imageB写到A区重启
之前官方合并工具也一直不好用，就使用外面别人写的合并工具。
