A wrong byte be send in the SMBus mode

[rzzuozuo]

Describe the set-up

• Board: ST Nuceo-L432KC
• IDE: IAR 8.22.2.

Describe the bug There will be byte data in I2C.TXDR before transmits in slaver mode.

How To Reproduce

1. Indicate the global behavior of your application project.

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...). Driver-SMBus.c

3. The use case that generates the problem.

4. How we can reproduce the problem. use ReadWord cmd in master to read a Read32 cmd, such as below.

   st_command_t const TEST_CMD[] = {
   ...
   {0x26, READ_OR_WRITE, 5, 4},
   ...
   }

   After 2 bytes send, the master will send NACK to stop transmission. For slave, the third byte will be in TXDR, and it can't be copied to the shift register(TXE = 0).

In the next transmit phase, a wrong byte will be transmitted after ack for ADDRF.

Additional context We can set TXE to 1 after every STOPF in smbus mode. .

[ASELSTM]

Hi @rzzuozuo,

Thank you for this report. Actually, even if in slave side, the third byte will be in TXDR, and it can't be copied to the shift register since TXE = 0, in the next transmit phase, hsmbus->Instance->TXDR will be reloaded with the values of *hsmbus->pBuffPtr within SMBUS_Slave_ISR()

https://github.com/STMicroelectronics/STM32CubeL4/blob/d023c0d560ace11509f9b761c8913a9e48fcf194/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_smbus.c#L2272

Unfortunately, we couldn't reproduce the described issue. If the issue is systematically reproducible on your side, would you please give us more details and share the project so that we can reproduce the same behavior.

With regards,

[rzzuozuo]

In the next transmit phase, a wrong byte will be transmitted after ack for ADDRF(ADDR ISR).

after this wrong byte from the shift register to bus, hsmbus->Instance->TXDR will be reloaded with the values of *hsmbus->pBuffPtr within SMBUS_Slave_ISR() (TXIS ISR)

The problem is hsmbus->Instance->TXDR = *hsmbus->pBuffPtr; can only run by TXIS ISR.In normal conditions TXE is 1,not 0.

[ASELSTM]

Hi @rzzuozuo,

Thank you for these details. We were able to reproduce this point you have reported and indeed the issue is confirmed. To fix this we suggest you to flush the TXDR register at the end of the transmission process so that at the next transfer it will be reloaded with the right values.

An internal bug tracker has been logged and a fix will be implemented and made available in the frame of a future release. Thank you once again for your contribution.

With regards,

[ASELSTM]

ST Internal Reference: 104028

[ASELSTM]

Hi @rzzuozuo,

This issue has been fixed in the frame of version v1.17.1 of the STM32CubeL4 published some time ago. Please allow me then to close it.

With regards,