STM32f407ZG使用STM32CubeMX创建USB应用失败
关于STM32的高精度定时器应用问题请求帮助
STM32L031X 1.65V 低压应用
L6470的应用问题,高速不转振动
STM32F1的IAP程序,APP1和APP2两个应用程序交替更新的问题
MDK能否仿真App应用程序(STM32起始地址不为0x08000000)?
现金悬赏-STM32F4Cube生成的USB HID应用无法接收数据
STM32F030F4P6待机模式唤醒应用问题
J-Trace调试器针对什么应用场合?
STM32的USB host CDC应用
点评
点评
我常用的有两种思路,两种各有优缺点。
第一种:在APP运行程序中接收到固件升级指令,跳转到Bootloader中,在Bootloader中接收待更新的固件数据,并且校验其正确性,把数据写到APP区,全部接收完成后,跳转到APP运行。这个方法的好处是,不需要额外的Flash区域,缺点是升级的端口协议相对固定、不自由。
第二种:在APP中接收待更新的固件数据,并且检验其正确性,再把数据写到备份区,完成后,跳转到Bootloader,在Bootloader中对备份区检查,如果有新数据,则把它搬到APP区,最后跳转到APP运行。这个方法的好处是,在APP中接收数据,APP里可以自由更换升级端口,比如串口,CAN,以太网等,应用中使用的什么端口,升级就可使用什么端口,Bootloader中只负责从备份区往APP区搬运数据。缺点就是需要使用和APP空间同样大小的备份区。