有人使用STM32G474RE芯片开发产品，涉及到片内FLASH的擦写操作。他基于STM32G4系列Cube库中关于FLASH擦写的例程来组织相关代码。

当我们从ST官方网站下载到STM32CubeG4固件包并解压后，该例程可以在下面目录位置找到：

例程主要基于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。

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

在做FLASH的擦写操作时，我们只需根据上面地址定义给出页起始地址和结束地址，即可进行相关页面的擦除。现在的问题是，针对BANK1的页进行擦写没问题，对BANK2的页擦写有问题。我们不妨一起看看到底怎么回事。

现在假设要对Page254进行擦写，即先擦除后写数据。这里的验证就只写32字节数据，内容是0x12345678。我们可从手册得知Page254的起始地址为0x807f000。

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

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

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

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

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

这里顺便验证关于STM32G4片内FLASH的两个问题。

第一个问题，如果在已擦除页的某些地方先写全F的内容，之后可以不经页擦除将这些FF改写为别的内容吗？【默认写操作遵守地址对齐约定】

我们还是以Page 254页作为擦写对象。先对该页进行擦除，然后在该页起始位置的连续32字节，写上FF内容。接着试图在这32个字节位置写上0x12345678，看看能否成功。

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

第二个问题，如果编译过程中通过常量定义的方式，用FF占用一些存储单元，之后可以对这些单元改写内容吗？前提是改写之前不对所在页做擦除。

这里仍以Page 254页作为验证对象。先通过const定义加指定存储方式，让该页首的前32字节内容保持为FF。

经验证，之前被定义的全FF的双字单元是可以在不做页擦除的前提下被改写的。

我们不妨多看几种情形。将常量定义调整下，看看结果如何。

我现在将第3个双字单元内容变为不是全FF内容，然后对第1个、第2个和第4个双字单元进行改写。见下面输出截图：

看来通过常量定义预留的第1个、第2个和第4个双字全FF单元都是可以被程序改写的。

我若将1个双字单元变为非全FF,其它3个双字依然保持全FF，在程序里尝试对第2、3、4双字单元进行数据改写，结果会怎么样呢？见下面输出结果截图。

从测试结果来看，通过常量定义预留的全FF单元在后期程序里是可以不经擦除直接改写的。当然，写入的流程和地址对齐规则还是要遵守的。

OK,关于STM32G4芯片FLASH擦写话题就聊到这里，权作提醒和参考。实验过程中使用的IDE是ST提供的免费IDE---STM32CubeIDE。上面的测试结果和结论不保证能套用到别的STM32系列，毕竟每个系列的FLASH管理机制并非完全一样，最终以具体的实际验证为准。