H743IIT6 Flash模拟EEPROM 踩过的坑:必须按32个字节编程

前言

笔者最近在写FLASH模拟EEPROM的内容，本以为就跟SDRAM差不多，结果还是踩了坑。

前期定义数组和写测试函数

首先，我定义了两个数组，一个是u32的数字数组，一个是u8的字符数组。

其次，我自己写了一个写入函数，主要步骤就是解锁和写入。

函数如下图所示：

最后，我还写了一个赋值函数，其主要作用就是将那一个扇区全部赋值为FF，便于我观察实验结果。

函数如下图所示：

关于其中的startaddr和endaddr，其实就是开始地址和结束地址，可以结合自己的具体情况进行设置。

而我选择的就是bank2的第0扇区。

如下图所示：

ok，接下来就开始测试过程（踩坑过程）。

测试过程和分析思路

首先，先打印出来，这两个数组成员的地址：

结果如下：

注意：我在这里只输出了两个w，而text_buffer_2中是有三个w的。

其次，就是开始进行仿真，并且把扇区全部赋值成FF。

然后执行上述的写入函数(FLASH_EEPROM_WRTIE_NOCHECK)。

得出来的结果如下图所示：

一开始，text_buffer是一个u32数组，所以其中的数组成员是32位的。

所以我们易得其中的成员1，转换成二进制就是：
0000 0001 0000 0000 0000 0000 0000 0000
转换成十六进制就是：
01 00 00 00
其他的都可以依次类推。

疑点

按理来说，我只打算写入text_buffer的内容，而不是text_buffer_2的内容，所以到06 00 00 00就应该是结束的了，可后面为什么还有一串值呢？
这让我很是疑惑。

可以看一看我下图的分析：
不难看出，在后面接着的，就是text_buffer_2的内容，其ASCII值转换成十六进制后就可以得到上述的结果。

但是，不难看出，后面跟着的内容它并不是完整的text_buffer_2的内容！

最后，我发现最后一个0x77的地址是0X08100020。其转换成十进制，刚好就是32，对应着32个字节操作，我回看上述的数组地址打印，其大小也是0X20。

结论

在上述的测试中，尽管我只是写入了text_buffer的内容，但是不可避免的在后面也发现了text_buffer_2的内容，所以说明对于flash编程，他都是以32个字节为单位的，如果写入内容不够，就会继续写入一些其他定义的东西（与写入数组地址临近的内容）。直至补充到32字节为止。

应对措施

1，提高数据的内存存放密度，尽量塞满32字节。

2，补0，补够32字节。

资料

其实，在资料中早已表明，编程是以256位为单位的，但笔者水平有限，有点坑不踩不知道，于是写下了这篇博客，希望可以为他人提供一些参考。

至此，疑问已经得到解决。