do_gc函数中如果status.dirty已经是SECTOR_DIRTY_GC，不应该再次设置gc标志，会触发flash复习。我移植到stm32片上flash时，开始flash驱动没加FLASH_ClearFlag请标志。测试发现有时写数据会写失败，而且之后永远都是失败，调试器软复位也没用。调试发现是FLASH_FLAG_PGERR标志置导致的，看代码应该是这里复写导致的。
又看了下，不止这一处有可能会复写。比如修改ENV时触发GC，而且被回收的扇区恰好是原ENV所在的扇区，这时原ENV的状态已经是ENV_PRE_DELETE了，gc移动该ENV时又会设置该ENV的ENV_PRE_DELETE标志。类似的情况应该还有不少。建议在write_status函数里加个判断，如果原来的状态已经是这个状态就不要写了。
还有希望EF_ASSERT宏可以配置关掉，哪怕写死成release模式下可以关闭也行。正式程序还有检查增加不少体积
do_gc函数中如果status.dirty已经是SECTOR_DIRTY_GC，不应该再次设置gc标志，会触发flash复习。我移植到stm32片上flash时，开始flash驱动没加FLASH_ClearFlag请标志。测试发现有时写数据会写失败，而且之后永远都是失败，调试器软复位也没用。调试发现是FLASH_FLAG_PGERR标志置导致的，看代码应该是这里复写导致的。
又看了下，不止这一处有可能会复写。比如修改ENV时触发GC，而且被回收的扇区恰好是原ENV所在的扇区，这时原ENV的状态已经是ENV_PRE_DELETE了，gc移动该ENV时又会设置该ENV的ENV_PRE_DELETE标志。类似的情况应该还有不少。建议在write_status函数里加个判断，如果原来的状态已经是这个状态就不要写了。
还有希望EF_ASSERT宏可以配置关掉，哪怕写死成release模式下可以关闭也行。正式程序还有检查增加不少体积