HAL CubeMX I2C slave NACK problem (STM32F446)

[YBOUR]

Technical environment :

-       Master : CM3 (Raspberry)

-       Slave : STM32F446

-       CubeMX : V4.23 (even tested with V4.26.1)

-       Normal transaction is : MASTER do a 4 bytes WRITE, then a 1 byte WRITE and at last, a 4 bytes READ.

The slave ACKed the WRITEs, but the READ command is NACKed by the slave (logic analyser view).

I have this problem when I have a delay (more than 1 ms) between the end of the second WRITE (STOP bit) and the HAL_I2C_Slave_Transmit_IT() call.

Without this delay, everything seems OK.

EDIT :

I’ve tested this same scheme on a :

•  new CubeMx I2C slave project on a STM32F302 board : the slave does a clock stretching with the same code. So, even with the delay, on the F302, the transaction will be OK.
• new CubeMx I2C slave project on a NUCLEO F446RE board : same problem than our customer board...
•  new CubeMx I2C slave project on a STM32F0308 - DISCO board : clock stretching is present, everything seems to be OK
•  new CubeMx I2C slave project on a STM32F767 NUCLEO board : clock stretching is present, everything seems to be OK

The only differences seem to be the internal I2C peripheral and the CubeMX HAL driver.

[Amel NASRI]

Hi @YBOUR​ ,

Try to check the I2C1 registers content on debug mode:

• Is clock stretching enabled (NOSTRETCH = 0 in I2C_CR register)?
• are there error flags set in I2C_SR registers?

I assume that stretch is supported by the master as it is working with STM32F3.

-Amel

[YBOUR]

Amel,

• CR1 = 0x0401 (peripheral enable=1 + ACK enable=1 + NOSTRETCH=0) : seems OK
• I've swaped the test on the other I2C peripheral : I2C1 => I2C3 : same result.
• SR1 and SR2 = 0....

Regards,

Yvan

[YBOUR]

@Amel NASRI​ 

Another new additionnal tests :

• new CubeMx I2C slave project on a NUCLEO F446RE board : same problem...
•  new CubeMx I2C slave project on a STM32F0308 - DISCO board : clock stretching is present, everything seems to be OK
•  new CubeMx I2C slave project on a STM32F767 NUCLEO board : clock stretching is present, everything seems to be OK

Yvan

[Laurent BEYLY]

Hi,

The ACK bit is only set after having called the HAL_I2C_Transmit_IT() or HAL_I2C_Receive_IT(). The ACK bit can not bit set before calling these functions, because they start by checking that the I2C bus is free (by testing the BUSY bit).

The FMPI2C1, present on the STM32F446 doesn't have the issue because the ACK has been replaced by a NACK bit in CR1 and the reset value allows to aknowlege in case of address match.

Best regards

Laurent

[YBOUR]

Hi @Laurent BEYLY​ ,

Thanks for your answer and explanations. But at this point, we can not change the hardware link by using other pins.

It's a big problem for us...

Regards,

Yvan

[Amel NASRI]

Hello,

Please note that the fix is available in the patch 1.24.2 of STM32CubeF4 package (already available on the web).

-Amel