i2c error

[hongjo]

Dear ST 

I have some question about i2c read functions 

Currently we use zephyr os (version 3.4.0) 

the stm32f412RGT used as the host and the host  reads a 5-byte value from another mcu used as a slave through

i2c

the following problem occurs once every 3 hours after that i2c gets stuck.

uint8_t rx_buf[5];

rc = i2c_read_dt(&cfg->bus, rx_buf, sizeof(rx_buf));

When the host reads the last byte 0x3f normally, it should send nack instead of ack to slave , but it seems that i2c is stuck because ack is sent to slave . Is there a way to solve this?

thanks

BR

MR.SHIM 

[Andrew Neil]

---

@hongjo wrote:

the following problem occurs once every 3 hours  

---

Is that exactly 3 hours, or just "some time around 3 hours" ?

Repeatable?

Schematic & details of the slave may help.

[hongjo]

Dear guru

It takes about 3 hours, but when it happens quickly, the I2C STUCK happens in 30 minutes.

When I modified the code on the slave to process it as if it received a nack even though the host sent an ack at the end of the read, the i2c stuck did not occur even after several days of operation

thanks

BR

Mr.shim 

[bmckenney]

In the F4 series, having the master-receiver generate a NACK after the final byte requires byte-by-byte management of the CR1:ACK bit. The flow control model requires setting ACK=0 while the (N-1)th byte is complete, before accepting the (N-2)th byte from the RXDR. This is a bit of a dance, but is described in RM0402 Sec 4.3.3.  [I much prefer later versions of the I2C unit, which know what a transaction is.]

Once the master-receiver has ACK-ed the (final) byte, it has handed over SDA to the slave-transmitter, so (in general) the master can't issue a Stop (or anything else).

It appears that the Zephyr driver doesn't always get this sequence right. I regret to say that you probably have to take this up with the Zephyr people. 

[Pavel A.]

See also:

https://community.st.com/t5/stm32-mcus-embedded-software/hal-i2c-mem-read-disables-interrupts/m-p/782102

[hongjo]

Dear bmckenney 

Is this issues only occurring in the STM32F4 Series ?

in the next Hardware Version , the MCU will be changed from STM32F4 Series to STM32H743

thanks

BR

Mr.shim 

[bmckenney]

I'm not sure I can catalog which devices have "old" vs "new" I2C units. The F103 and (based on RM0402) the F412 have the "old" ones and the H723, WL55, and (based on RM0433) H743 have the "new" ones. (Splitting "old" vs "new" might also be an oversimplification, since there may be variations in either category.)

The tipoff is in register CR2: In the "old" units, CR2 (+ CR1) has a bunch of micro-management bits, but in the "new" one CR2 has address/RW/length/start/stop -- everything you need for a transaction, so you (mostly) just let the I2C unit do its thing.