stm32h743 FM25CL64铁电存储器踩坑记录

铁电模块的时序要求相对比EEPROM较低，理论上写入字节后不需要延时即可写入下一个字节，且不同于FLASH，不存在只能从1转为0的情况，不需要将数据位提前写入FF。铁电的数据存储也不是页操作，直接向相应地址写入字节即可。

调试FRAM经验总结：

1、跑完FRAM读写代码之后，逻分仪发现总线上只有简单、短暂的电平变化，明显不是SPI的通信数据。

（经提醒发现连片选拉高拉低都没有执行到位）

后来发现是因为片选引脚没有初始化，所以直接拉高拉低是无效的。

2、引脚成功初始化后发现CLK、MISO、MOSI数据仍不正常。通过加打印的方式发现跑到HAL_SPI_Transmit中之后还没有执行到写SPI数据寄存器的那一步就return了。

后来经提醒发现：

上图中的指针使用方式错误

后来又发现：

打印出来发现两个值不一样，说明赋值无效。这才想到传进来的指针有问题：

不可以把SPI3基址作为SPI3总线句柄传进去（现在看这么用好弱智）。指针不能这样用。

 3、通过SPI读写FRAM，最后一个字节有时会出错：

是由于时钟频率太快导致。（裸机代码SPI3 时钟分频是8，我现在错误情况下分频是 2）

分频256 的波形：

 

注意点：

1. CLK高低电平没有均匀分布，是因为只有在SPI设备工作（启动传输）的时候才会发时钟信号。代码里也有体现：

 

 写数据的波形分析：

读数据的波形分析：

 

为啥从上层APP下来是跑到 HAL_SPI_Transmit ??

发现的问题：

APP跑下来到HAL_SPI_Transmit是由于驱动里写的msgs.flag 的值导致跑过去的，不知道为啥从APP跑到HAL_SPI_Transmit会导致系统崩溃。（客户提供的源码是用的HAL_SPI_TransmitReceive）

改了msgs.flag跑到HAL_SPI_TransmitReceive 就不会崩溃了。