flash_load_env 如果闪存中的数据是垃圾数据env 初始化故障.

flash_read(get_env_system_addr() + FLASH_ENV_SYSTEM_INDEX_END_ADDR * 4, &env_end_addr, 4);
    /* if environment variables is not initialize, set default for it */
    if (env_end_addr == 0xFFFFFFFF) {
        flash_env_set_default();
    } else {
        /* set environment variables end address */
        set_env_end_addr(env_end_addr);

如果闪存中是垃圾数据, 或者是说读取的env_end_addr非法,直接调用set_env_end_addr, 设置一个错误的值,是不是有问题??

如果 env_end_addr非法，同时还能从闪存读取会数据，那么接下来CRC32校验肯定会出错，此时会复位环境变量到默认。如果读取地址有问题，那么软件可能直接就进HardFault了。

使用时要保证env_end_addr数据不被用户去修改。

所以出现那么软件可能直接就进HardFault了是不好的,我已经验证过了,就是计算CRC时,从env_cache溢出了,传递给calc_crc32的size参数非法,内存溢出了,我觉得这时候应该有较好的容错性处理.

如果只是防止HardFault，我可以在增加个对于 env_end_addr 地址边界的判断。但是真正从实质上预防垃圾数据，你有没有更好的建议呢？

可以在地址前添加一个字符串来进行校验吧比如“easyflash”,如果比较字符串通过，后面就不是垃圾数据

实际上,只要环境变量区的数据是不动的,那么执行流程也是对的,但是当遇到环境变量区的配置发生变化时,而新配置的目标Flash Sector中已经存在垃圾数据,这样在使用的过程中(尤其是开发的过程中,当然次数也不是非常多),一运行嵌入式系统死机.这种体验是非常糟糕的.常常要把那片Flash Sector擦掉或者用命令写默认的参数才能解决.

env_end_addr 边界肯定不超过env section size.可以用二进制扫描的方法, 设置一个环境变量结尾标记,或者是扫描到0xFF则停止,这样虽然慢,但是稳妥第一.所以用扫描(也就是对env_end_addr地址边界判断)和CRC双重保护,应该能防止垃圾数据.或者使用双CRC的方法.

好的，感谢反馈哈~

状态更改为 已关闭

GVP 朱天龙 (Armink) / EasyFlash

内容风险标识

评论 (7)

GVP朱天龙 (Armink) / EasyFlash

内容风险标识