Posted on July 11, 2018 at 12:12I hope some can help with a SMBus problem I am having. I am using I2C2 on the STM32L432 in SMBus mode as communication medium between devices. I'm not using the standard SMBus protocols, instead I'm using a simple data link protocol to exchange variable length messages.
I've experienced a number of limitations and issues with the way the STM32Cube HAL library for SMbus behaves, so I have adpted it to suite my needs. One of the changes I have made is to use the NBYTES count for Slave receives rather than have the ISR reconfigure the I2C peripheral for every byte.
My SMBus slave needs to receive the message in 2 parts: a header part and a data part. The Header part is always fixed length (2 bytes) and includes a command, plus a length for the following data part. I'm also using PEC so there is a PEC byte on the end of the data part.
The first part is received correctly but the data part fails with a PEC Error after receiving just 2 bytes, even though there was at least 12 bytes of data.
All slave receives are performed with SBC=1.
For the Header NBYTE=2, RELOAD=1, PECBYTE=1.
Clock stretching occurs while we set-up to receive the data part: NBYTES=13, RELOAD=0, PECBYTE=1.
For the data part I expect the device to perform a PEC check on the 13th byte however it stops after the second data byte with a PEC ERROR seemingly having treated NBYTES as 2.
If I increase the the header size to 4 bytes, then I get the PEC Error after 4 bytes of data.
I confirmed that CR2 does contain 13 in the NBYTES fields before the receive.
I've been over the reference manual and I cannot find any constraint on writing to the NBYTES field of CR2. It appears as though the I2C has some internal copy of NBYTES from the header receive the it keeps using.
I'm starting to think there is a bug in the I2C peripheral hardware.
Is there something I'm missing in order to get the I2C to accept the reload value for NBYTES?
Cheers,
Andrew.
