关于STM32芯片的Flash意外被擦除的问题

只看该作者 · 2014-12-17 16:38

目前使用STM32 F407做一个项目，遇到了内部Flash里的程序有时会意外被擦除的情况，请高手帮忙分析分析情况。

类似的问题在论坛里也有一些人提出来过，不过没有找到对我有帮助的答案。

具体的情况是：

程序用J-Link下载到F407里之后，可以正常运行。但偶然情况下程序就运行不起来了，重新再用J-Link烧录一遍固件，板子就有可以正常工作，一点没问题。所以就怀疑程序运行不起来的时候是程序已经不在Flash里了。后来把出问题的板子里的Flash里的内容通过J-Link往外读，发现确实里面的内容有大概几百个Byte变成了0x00，也就是说Flash里的内容被意外写零了，但不是全部，就是整个程序中间的一部分。

如果正常使用，差不多1，2天就会出现一次这种情况，再重新烧录就又能正常使用1，2天，如果人为将故障复现，可以在电源出迅速上电，断电，就比较容易出现此种情况，所以此种情况似乎和电源不稳定有点儿关系，可为什么又会将Flash意外擦除呢？

再简单描述一下硬件: 很简单，就是标准的F407一块加上一个USB的物理层（因为是2.0高速），整块板由USB的Vbus供电，即Vbus接1117-3.3，然后1117的3.3V给MCU和USB的PHY供电。MCU的两个BOOT都是通过下拉电阻接地。NRST只是接到了J-Link的接口上，因为没有按键复位的需求。按手册上的图，NRST对地应该接个0.1uF的电容，我没有接，不过这应该不是导致Flash被改写的因素。板子整体的耗电量大约是120mA,远小于USB可提供的500mA。

所以目前急切想请教高手：
1. 在什么样的情况下，会导致STM32内部的Flash中的一小部分被意外改写成0。
2.即使硬件设计中存在不合理的地方，F407或STM32的MCU本身有什么防护措施能防止这种情况发生？

只看该作者 · 2014-12-17 18:22

你不要加密，当出现问题时，用st-lint读出来比较一下是否一样，先排除是flash被改写还是程序有问题。

1万 · 2014-12-17 18:42

第一个问题貌似在掉电的时候会出现。。。

只看该作者 · 2014-12-17 20:08

泰山特曲123 发表于 2014-12-17 18:22
你不要加密，当出现问题时，用st-lint读出来比较一下是否一样，先排除是flash被改写还是程序有问题。 ...

我就是没有加密，我程序里除了Flash的必要初始化之外也没有任何对Flash的操作。

用J-Link读出来的比较结果就是确实二进制代码中的几行被改写成零了，和原始刚烧录进的固件不一样。

1万 · 2014-12-17 21:09

错误地改写, 是有可能的, 不过这个问题不容易定位bug 原因.
可以考虑使用写保护机制来屏蔽可能的意外改写

3万 · 2014-12-17 21:54

烧写的时候先整片删除看看；

只看该作者 · 2014-12-17 22:45

mmuuss586 发表于 2014-12-17 21:54
烧写的时候先整片删除看看；

这个方法试过，每次重新烧写的时候整片擦除再写，但是问题没有解决

只看该作者 · 2014-12-17 23:49

如果你的程序不改写flash，应该不需要对flash进行初始化的。是不是你的代码有改写flash啊？把写保护使能看看。

2万 · 2014-12-17 23:51

启用写保护WRP

只看该作者 · 2014-12-18 08:49

楼主的代码里面有指针吗？

只看该作者 · 2014-12-18 09:02

泰山特曲123 发表于 2014-12-17 23:49
如果你的程序不改写flash，应该不需要对flash进行初始化的。是不是你的代码有改写flash啊？把写保护使能看 ...

在初始化时钟的最后要设置一下FLASH_ACR寄存器啊，设置Flash的Latency什么的。涉及Flash控制的仅下面一条语句：

/* Configure Flash prefetch, Instruction cache, Data cache and wait state */
FLASH->ACR = FLASH_ACR_ICEN |FLASH_ACR_DCEN |FLASH_ACR_LATENCY_5WS;

只看该作者 · 2014-12-18 09:03

wxh0000mm 发表于 2014-12-18 08:49
楼主的代码里面有指针吗？

有，但没有操作PC指针的。

只看该作者 · 2014-12-18 09:37

mcuisp 发表于 2014-12-17 23:51
启用写保护WRP

我曾经试过用J-Link的“J-Flash ARM”中的“Secure Chip”将407加密，在这种情况下，按说是启用了读保护，而读保护有效时Flash的0-3页的写保护不是也是有效的吗？
这种情况下依然有被改写的情况。但出问题后写保护使能位还是有效的，也就是读不出Flash里的内容。

我的代码并不是很长，一般被改写的位置在Flash的起始地址不远处，也就是0x0800 0040这个位置前后，每次不一定完全相同，但是大致就是这个位置。被改写的长度大概每次都是200多Byte吧，后面就又都正常了。

2万 · 2014-12-18 11:14

加密是指读保护RDP，与写保护WRP不一样。
另外有个更毒的办法，是复位后先向 Unlock KEY字写入错误的序列。:lol

只看该作者 · 2014-12-30 10:44

mcuisp 发表于 2014-12-18 11:14
加密是指读保护RDP，与写保护WRP不一样。
另外有个更毒的办法，是复位后先向 Unlock KEY字写入错误的序列。 ...

写成写保护WRP之后测试了一段时间后依然出现了问题。
这次只加了写保护没加读保护，使用一段时间后，程序又跑不起来了。读出来一看，整片内容被擦除了。

也就是说，如果不作写保护，出现问题时是Flash里的内容的一小部分被改写成了0x00,作了写保护后，出现问题时全片被写成了0xFF，也就是全片被擦除。我试过当读写保护全部加上，再通过J-Flash ARM的Unsecure Chip命令解除写保护时，全片就会被擦除，也就是说，在写保护的情况下，片子是有可能被全部写0xFF的。难道必须使用OTG给烧成砖头吗？

问题总是出在电源插拔时，如开始所说是USB供电且接口处作必要ESD处理，然后Vbus接1117-3.3。有人对从供电角度解决此问题有啥建议没？