云途YTM32B1MD14，程序位于PFlash0，需要对 PFlash0进行Program 操作，怎么实现？
-
项目用的云途YTM32B1MD14 MCU, FLASH一共是512K，bootloader flash地址从0x0000开始，大小是64K,实际bootloader工程编译出来的大小是57K左右。APP flash从0x10000开始，0x457FF结束，一共大小是214K，实际app工程编译出来的大小是201K。项目要求要有AB备份的方式（升级失败后要能继续使用当前的app程序），所以APP 备份区从0x45800开始，0x7AFFF结束，大小是214K。另外项目要求用户配置信息断电需要有记忆，由于YTM32B1MD14没DFlash，还从PFLASH1设置了20K的空间来做EEPROM数据，从0x7B000开始，0x7FFFF结束。现在升级的策略是这样的，在APP中将目标版本的数据先刷写在APP 备份区，数据全部刷写完成后，重启跳到boot，boot工程再从APP 备份区拷贝到APP区。这样就有一个问题，boot运行在PFLASH0，需要对PFlash0进行Program 操作，但是云途YTM32B1MD14 这款MCU的Flash控制器对同一个Block不支持RWW操作。为了解决这个问题，我在云途论坛上看到有个博主写道，程序位于PFlash0，然后Program PFlash0需要采用同步模式，并且关闭中断的方式，但是博主没有说具体怎么实现，哪位大神有程序位于PFlash0，需要对 PFlash0进行Program 操作的具体实现方式吗？最好能提供代码，谢谢！！！
-
风清扬 按照上面提到的方案，使用pflash0中的BOOT将APP备份区的数据拷贝到APP区需要擦除原有的APP区，并将备份区的数据编程到APP区，该过程中擦除和编程操作前注意调用INT_SYS_DisableIRQGlobal()关闭全局中断，操作完成后再调用INT_SYS_EnableIRQGlobal()开启全局中断即可。
不推荐使用这种方案，如果使用这种方案，需要在BOOT中保留flash驱动代码，若软件运行过程中跑飞，存在误擦风险。建议评估是否可以使用如下方案：
划分APP1，APP2两块区域用来实现升级/回滚，例如升级UDS服务中首先判断当前软件运行在哪块区域，若运行在APP1，升级时将更新软件刷在APP2中，复位后在BOOT中判断APP2有效位，若有效直接跳转到APP2入口地址运行，否则正常运行APP1. -
YQH 程序位于PFlash0，需要对 PFlash0进行Program 操作，只需要擦除和编程操作前调用INT_SYS_DisableIRQGlobal()关闭全局中断，操作完成后再调用INT_SYS_EnableIRQGlobal()开启全局中断，就可以吗？ 至于你提到的，1.BOOT中保留flash驱动代码，若软件运行过程中跑飞，存在误擦风险。 回复：这个不会出现误擦除的，我们的升级流程，需要先发送flash driver文件，flash driver数据保存在ram中，没有flash driver接口的时候，是无法进行擦除跟编程操作的。 2.建议评估是否可以使用如下方案：
划分APP1，APP2两块区域用来实现升级/回滚，例如升级UDS服务中首先判断当前软件运行在哪块区域，若运行在APP1，升级时将更新软件刷在APP2中，复位后在BOOT中判断APP2有效位，若有效直接跳转到APP2入口地址运行，否则正常运行APP1. 回复：这种方案在实际项目软件迭代中，管理起来会比较麻烦，比如，有V1.1 ,V2.1 ,V3.1 ,V4.1 ,V5.1 ,V6.1 软件版本，对应app1跟app2的升级文件是不一样的，我们是做汽车零部件的供应商，比如我现在要升级成V6.1的版本，但是车子上的软件版本有可能是是V1.1_app1,V1.1_app2,V2.1 _app1,V2.1 _app2,...V5.1 _app1,V5.1 _app2中的任意一种，这样升级的话，4S店的技术人员根本就不知道要用V6.1_app1,还是V6.1_app2来升级，也很混乱 -
我们YCT工具都有DEMO
-
请教一下，哪位手上有没有云途YTM32B1MD14，Keil工程的bootloader和app参考工程？还就好Lz一样吐槽一下，Keil的默认设置，奇葩啊，MD14 flash=256+256 ram=32+32，默认配好误导人啊
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...