STM32G4片内FLASH擦写实验笔记

嵌入式大杂烩

有人使用STM32G474RE芯片开发产品，涉及到片内FLASH的擦写操作。他基于STM32G4系列Cube库中关于FLASH擦写的例程来组织相关代码。
当我们从ST官方网站下载到STM32CubeG4固件包并解压后，该例程可以在下面目录位置找到：

pddm3oy3jyt6401714757.png

例程主要基于STM32G474RE及双BANK模式进行编程和验证测试。
STM32G4系列里的STM32G47x芯片是支持双BANK的。目前用户使用的STM32G474RE，内置512K Flash，可以配置成单BANK或双BANK。此时用户采用双BANK架构，他发现对BANK1的page进行擦写没有问题，对BANK2的page进行擦写则有问题。
从手册上看，当使用双BANK时，PAGE编号是两套重复的。以512K Flash为例，BANK1 和 BANK2 都有page0~~page127的编码,每页2KB,共256page。

e3hz5mkxpc26401714857.png

例程代码里做Page跟地址对应的定义时，是按照地址从低到高依次定义了256页的地址，即按page0到Page255做了定义。

ysfrvhzqnfq6401714957.png

在做FLASH的擦写操作时，我们只需根据上面地址定义给出页起始地址和结束地址，即可进行相关页面的擦除。现在的问题是，针对BANK1的页进行擦写没问题，对BANK2的页擦写有问题。我们不妨一起看看到底怎么回事。
现在假设要对Page254进行擦写，即先擦除后写数据。这里的验证就只写32字节数据，内容是0x12345678。我们可从手册得知Page254的起始地址为0x807f000。

c5wd21gqy5v6401715057.png

其它代码沿用例程不动，经测试发现Page254的确没有被擦除，数据也没有正确写入。

i233lh14hgj6401715157.png

借助STM32CubeIDE调试器可以发现，目前程序根据所给定的page起始地址计算得到Page编号为126，作为双BANK来看的话，这个编号是没问题的。但是，BANK编号还是BANK1，这就有问题了。

yerjzats5bd6401715258.png

【注：BankNumber变量是我为了方便调试加的】按理这里应该是BANK 2才正确。我们可以进一步查看代码里根据地址计算BANK编号的代码。

c5bw1rqs5qp6401715358.png

这里求算BANK编号的函数就有点仓促了，只是简单直接返回BANK1编号，显然不合理。当然，如果期望这里写得通用性很强，就得结合不同型号的FLASH容量大小来写，地址超过整个片内FLASH容量一半则为BANK2。我这里只基于STM32G474RE来对这个获取BANK号的函数做些小修改，然后验证。

tnsuhdjbitw6401715458.png

经过上述调整后，再次运行测试，结果正常了。

5iwwyypes4w6401715558.png

这里顺便验证关于STM32G4片内FLASH的两个问题。
第一个问题，如果在已擦除页的某些地方先写全F的内容，之后可以不经页擦除将这些FF改写为别的内容吗？【默认写操作遵守地址对齐约定】
我们还是以Page 254页作为擦写对象。先对该页进行擦除，然后在该页起始位置的连续32字节，写上FF内容。接着试图在这32个字节位置写上0x12345678，看看能否成功。

1ly531cdqhq6401715658.png

经测试，即使之前写的是全F，在不做擦除的前提下，再次想改写这些全F单元是行不通的，至少这里行不通。下图是验证结果。

awsqqil0qwp6401715758.png

第二个问题，如果编译过程中通过常量定义的方式，用FF占用一些存储单元，之后可以对这些单元改写内容吗？前提是改写之前不对所在页做擦除。
这里仍以Page 254页作为验证对象。先通过const定义加指定存储方式，让该页首的前32字节内容保持为FF。

31ymztxhffr6401715858.png

经验证，之前被定义的全FF的双字单元是可以在不做页擦除的前提下被改写的。
我们不妨多看几种情形。将常量定义调整下，看看结果如何。
我现在将第3个双字单元内容变为不是全FF内容，然后对第1个、第2个和第4个双字单元进行改写。见下面输出截图：

px4y1j1bd4c6401715958.png

看来通过常量定义预留的第1个、第2个和第4个双字全FF单元都是可以被程序改写的。
我若将1个双字单元变为非全FF,其它3个双字依然保持全FF，在程序里尝试对第2、3、4双字单元进行数据改写，结果会怎么样呢？见下面输出结果截图。

tl1seyvx0o06401716058.png

从测试结果来看，通过常量定义预留的全FF单元在后期程序里是可以不经擦除直接改写的。当然，写入的流程和地址对齐规则还是要遵守的。
OK,关于STM32G4芯片FLASH擦写话题就聊到这里，权作提醒和参考。实验过程中使用的IDE是ST提供的免费IDE---STM32CubeIDE。上面的测试结果和结论不保证能套用到别的STM32系列，毕竟每个系列的FLASH管理机制并非完全一样，最终以具体的实际验证为准。
猜你喜欢：
Github上热门 C 语言项目汇总！
嵌入式，可测试性软件设计！
一些低功耗软件设计的要点！
嵌入式 C 保护结构体的方式
实用 | 10分钟教你通过网页点灯
谈谈嵌入式软件的兼容性！