MM32F013x I2C连续写入EEPROM 24C02数据时从机不应答检测

2020-12-2 12:06

本帖最后由 whatcall 于 2020-12-2 12:08 编辑

如题，当我们连续写入EEPROM数据时，如果重新向EEPROM发送数据：START | EEPROM器件地址+Write位，EEPROM会因为内部在执行数据更新而无法及时接收数据，此时会返回NACK（即在传输的第9个bit不拉低SDA）。目前MM32F030的例程并没有处理这一种情况，基本上是利用延时来解决的。但是延时的做法存在一定的弊端：（1）不能最大化地利用EEPROM的性能；（2）当EEPROM出现其他故障时，也无法确认写操作的完成。

不知道有没有朋友深入研究过这种情况的处理方法？STM32和HC32均有NACK的检测机制，可以很容易地检测到NACK和ACK的状态。

2020-12-2 16:44

理论上，I2C在任何时刻都不应该采用主动延时的方法控制程序流程。四年前我们MM32-EVB的演示例程可以确定是正确的。

2020-12-2 21:50

zhu^zhu 发表于 2020-12-2 16:44
理论上，I2C在任何时刻都不应该采用主动延时的方法控制程序流程。四年前我们MM32-EVB的演示例程可以确定是 ...

核心问题是MCU为主机发送时，能否检测到从机的NACK？

2020-12-3 10:06

不要加delay

2020-12-3 13:43

whatcall 发表于 2020-12-2 21:50
核心问题是MCU为主机发送时，能否检测到从机的NACK？

能否检测到对方发出的ACK(NACK)，是设计I2C IP硬件必须关注的，相信I2C硬件检测了这个信号。

2020-12-3 13:58

zhu^zhu 发表于 2020-12-3 13:43
能否检测到对方发出的ACK(NACK)，是设计I2C IP硬件必须关注的，相信I2C硬件检测了这个信号。 ...

一般我们有理由相信MCU的I2C外设会有这个检测机制，然而，MM32F013x（实际上可能是灵动微所有的M0核MCU）都忽视了这一点，除非隐藏在某个功能背后没有显式地描述出来。

专栏首页

MM32F013x I2C连续写入EEPROM 24C02数据时从机不应答检测