|
同时发现一个比较让人困惑的地方 以下是flash擦除部分的代码 // 擦除一ROW数据 FLASH_PageErase( StartAddress ); // 等待擦除完成 while( status != HAL_OK ) { status = FLASH_WaitForLastOperation(FLASH_TIMEOUT_VALUE); } CLEAR_BIT(FLASH->CR, FLASH_CR_PER); // 写入数据 FlashWriteNoCheck( StartAddress,FlashBuff,FMC_SECTOR_SIZE ); 原工程这里有个CPU查询flash擦除是否busy 但是我查了手册说擦除flash的时候cpu会自己stall 比较好奇这个cpu都有时间执行这条检查是否busy的指令了 那就说明肯定不stall 也就是肯定擦完了呀 这条代码在我看起来有点莫名其妙的感觉 但是我查阅网上说这个才是标准写法 |
在擦除flash时 同时挂起中断 是否会造成卡死以及相关的卡死机制
STM32F407VET6,使用cubeIDE下载跑不起来
STM32F417 RTC读取亚秒寄存器
HAL_I2C_Mem_Read 一直返回 BUSY
STM32F207IG 10Mbps 半双工以太网异常
STM32F103C8T6 上电后无法通过串口发出数据的问题?
STM32L562DK探索板——初试Audio
STM32L562DK探索板——触摸板测试
STM32F405ZGT6 批次22+ 问下这颗料,60度烘烤12小时后,出现鼓包,是怎么回事? 原厂有标准的烘烤温度范围 跟时长范围吗?
STM32L562DK探索板——点灯
微信公众号
手机版
也没有什么莫名其妙的。
你说能正常执行到这个标志检查时,说明不是stall状态是对的。但待退出之后,再检查这个标志
就是很自然的一件事情。
就好像你在做一件事情,正在忙的时候不会理睬他人的要求,做完后方可以响应别人的要求一样。当你做完事情,别人问你此时忙不忙,你当然知道自己此刻忙不忙,或者说忙完没有。
在同区做flash擦、写时,的确是有这个临时堵塞问题。所以,这时候要特别注意这个过程中其它中断的处理问题,如何处理结合应用场景来。
有条件的话,可以选用双FLASH bank 芯片来操作,对于没有双BANK的,可以考虑将那部分不期望FLASH擦写影响的代码,主要是中断服务程序放到RAM也是可以的。
但如果这段函数本身是从 Flash 执行的,那么在擦除开始后程序会因为 Flash busy 而 stall,因此它表现为一个阻塞等待函数。
如果把这段代码及依赖搬到 RAM,那么 CPU 就能在后台擦除Flash 的同时,真正地轮询BSY 位 来等待操作完成。
原来如此 感谢解答
从硬件角度看,CPU擦除的肯定不会和CPU执行指令的是同一个FLASH分区,比如升级固件操作