干扰环境下Flash数据丢失--逻辑验证

Jerryzgj

干扰环境下Flash数据丢失--逻辑验证 [复制链接]

      在使用中遇到STM32的Flash数据莫名丢失的问题，在网上找到一篇ST官方给出的文档，其中指出了干扰环境下Flash数据丢失的解决办法是用逻辑验证，大家看看这个逻辑验证具体应该怎么实现？或者用什么样的方法实现？下面给出ST文档的原文。（辛苦一下抄写一遍，方便大家阅读）
文档原文Start：
                                                   干扰环境下Flash数据丢失
问题：
该问题由某客户提出，发生在STM32F103VBT6器件上。据其工程师讲述：其产品中使用了STM32，已批量生产。其部分产品在交予客户使用一段时间之后出现故障。其工程师在对故障产品进行分析时发现，STM32的Flash中的部分数据丢失，原数据皆被0xFF取代。丢失数据的Flash区间的地址不固定，大小也不固定，呈一定随机性。该现象只在车载环境下发生，而在实验室无法复现。
调研：
检查硬件设计，核对VDD、VDDA、VBAT、Vref+、Vref-、VSS、VSSA、NRST、BOOT0、BOOT1等管脚的周边电路设计，未见异常。检查软件设计，发现其中有对Flash进行擦除和写入的操作，分别如表（二）及表（一）所示：
unsigned char flash_write_operate(u32 Address, u16 *buff, u32 len)
{
volatile FLASH_Status FlashStatus;                            (1)
u32 Temp_Addr;
FlashStatus = FLASH_COMPLETE;                            (2)
if(len%2) return WR_LEN_ERR;
if(Address%2)    return WR_ADDRESS_ERR;

   FLASH_Unlock();

   //Clear all pending flags
   FASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP |
                  FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR);
   Temp_Addr = Address + len;
   while((Address < Temp_Addr) && (FlashStatus == FLASH_COMPLETE))
   {
            FlashStatus = FLASH_ProgramHalfWord(Address,  *buff);
            Address = Address + 2;
            buff ++;
   }
   FLASH_Lock();
   if(FlshStatus == FLASH_COMPLETE) return FLSH_OP_OK;
   else
            return  FlashStatus;                                           (3)
}

                                                         表（一）

unsigned char flash_ereas_page(u32 page_num)
{
volatile FLASH_Status FlashStatus;                            (1)
FlashStatus = FLASH_COMPLETE;                            (2)

   FLASH_Unlock();

   //Clear all pending flags
   FASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP |
                  FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR);
   FlashStatus = FLASH_ErasePage(page_num);
   FLASH_Lock();
   if(FlshStatus == FLASH_COMPLETE) return FLSH_OP_OK;
   else
            return  FlashStatus;                                           (3)
}

                                                         表（二）

修改这两个函数，对函数体内的代码只保留其中的行（1）、行（2）、行（3），其余全部删除。重新编译后更新到之前出问题的若干产品中，然后将这些产品安装到原来的工作环境中长期测试，结果显示更新软件后的产品不再出现Flash中数据丢失的现象。

结论：
干扰造成SYM32中的程序跑飞，从而错误的执行了对Flash进行擦除或写入操作的代码，最终导致Flash中的内容丢失。

处理：
软件中要保证对Flash擦除或写入的操作的可控性，要有严格的逻辑验证，否则最好不要在软件中加入这样的代码。

建议：
什么事可控性？如何做到严格的逻辑验证？在这个问题上不防借鉴一下成功的案例：美国导弹核潜艇上对导弹发射按钮的管理。核武器的威力是强大的，发射按钮的管理权掌握在单个人手里是可怕的。为了避免如此危险的武器被滥用，在导弹核潜艇上，导弹的发射按钮是由三个人共同管理的。艇长、副艇长各有一把钥匙，武控官掌握着口令。发射导弹时，必须由武控官输入口令，然后艇长、副艇长同时用各自的钥匙操纵各自的按钮，导弹才得以发射。考虑特殊情况，如果某个人通过特别的手段同时掌握了两把钥匙和口令，能否发射导弹？答案是不能。因为艇长、副艇长和武控官各自的作业位置相聚很远，而且有时间限制，一个人是无法完成这三项作业的。如果艇长、副艇长和武控官合谋又如何呢？还是发射不了导弹。因为发射导弹的另一半口令和导弹的瞄准参数根本不在潜艇上，只有在下达核攻击命令时才通过密文发给潜艇。甚至，在导弹发射之后，艇上人员也无从知道它将飞往何处，也控制不了。这样，强大的武器最终掌握在中央指挥机关的手里。回到STM32的问题，如表（一）、表（二）所示的函数，谈不上逻辑验证，一旦被调用会毫不犹豫的执行下去，而不在乎调用是否合法。为了避免Flash被误擦、误写，STM32在硬件设计上时有所考虑的，就是在擦除或写入之前，必须验证口令，如果口令不对，Flash控制器拒绝相应的操作。然而，表（一）、表（二）所示的函数中，口令的验证形同虚设，没有起到应有的作用。因为在这两段程序中，口令的验证是无条件通过的。犹如锁上门后，却把钥匙留在锁眼里，是不能防盗的。仿照核潜艇的管理思路给出一个一般性的流程，如表（三）所示，供参考。