I2C migration STM32F2 to ST32F7

[andywild2]

Dear Sirs,

we had a project with the F2 using HAL_I2C_Master_Sequential_Transmit_IT() with Option I2C_FIRST_FRAME and a second HAL_I2C_Master_Sequential_Transmit_IT() with Option I2C_LAST_FRAME.
All worked perfect.
Using this Software with a F7 did not work. After the first HAL_I2C_Master_Sequential_Transmit_IT() with Option I2C_FIRST_FRAME a STOP-Condition occured and transfer stopped.

After hours of debugging through the HAL it turned out that I2C_FIRST_FRAME does notz set the RELOAD bit but 
I2C_FIRST_AND_NEXT_FRAME does and all workes fine.

So my question is: What is the usage of I2C_FIRST_FRAME in a F7 context, becuase it sets AUTOEND and nothing else. So how can be I2C_FIRST_FRAME the correct option for a sequence of frames?
best regards
Andy

[TDK]

> What is the usage of I2C_FIRST_FRAME in a F7 context

The meaning of I2C_FIRST_FRAME is the same in the HAL F7 library as in the HAL F2 library. If it is not working, it is probably due to a code bug or a difference in the hardware. Consider looking at the SDA/SCL signals directly with a logic analyzer to understand what is happening. Ensure HAL_I2C_IsDeviceReady returns HAL_OK before doing any other HAL_I2C_* function.

      (++) I2C_FIRST_FRAME: Sequential usage, this option allow to manage a sequence with start condition, address
                            and data to transfer without a final stop condition
      (++) I2C_FIRST_AND_NEXT_FRAME: Sequential usage (Master only), this option allow to manage a sequence with
                            start condition, address and data to transfer without a final stop condition,
                            an then permit a call the same master sequential interface several times
                            (like HAL_I2C_Master_Seq_Transmit_IT() then HAL_I2C_Master_Seq_Transmit_IT()
                            or HAL_I2C_Master_Seq_Transmit_DMA() then HAL_I2C_Master_Seq_Transmit_DMA())

[andywild2]

Hello TDK,
Maybe the intention of I2C_FIRST_FRAME usage was to be the same in the F7 context as it was in F2. But that is only wishful thinking. And the F7 chip does not care about this at all.
I will explain the situation in detail:
- I use the newest HAL 1.3.3
- I have no code bug because as I wrote it is all working as soon as use I2C_FIRST_AND_NEXT_FRAME in the first  HAL_I2C_Master_Sequential_Transmit_IT()

- I do use an logic analyzer, because with this I found the STOP-Condition and stopping of the transfer

The key point of the whole issue is that the F7 chip has a much more sophisticated I2C as the F2.
In order to continue with the next frame in a multiple frame situation in the F7 the RELOAD Bit24 in I2C_CR2 has to be set, prior to do the second HAL_I2C_Master_Sequential_Transmit_IT().

Here is the definition of I2C_FIRST_FRAME and I2C_FIRST_AND_NEXT_FRAME in line 301 of stm32f7xx_hal_i2c.h:

#define I2C_FIRST_FRAME                 ((uint32_t)I2C_SOFTEND_MODE)

#define I2C_FIRST_AND_NEXT_FRAME        ((uint32_t)(I2C_RELOAD_MODE | I2C_SOFTEND_MODE))

You can see clearly: I2C_FIRST_FRAME DOES NOT HAVE ANY RELOAD function!

When using the first HAL_I2C_Master_Sequential_Transmit_IT() with I2C_FIRST_AND_NEXT_FRAME the Reload Bit24 is permanently stored in the I2C_CR2.

But when using the first HAL_I2C_Master_Sequential_Transmit_IT() with I2C_FIRST_FRAME the Reload Bit24 is NOT set in the I2C_CR2!

Thereafter when calling the SECOND HAL_I2C_Master_Sequential_Transmit_IT() with Option I2C_LAST_FRAME the following error happens:

Within HAL_I2C_Master_Sequential_Transmit_IT() at line 3422 of stm32f7xx_hal_i2c.c this local variable is defined:
uint32_t xferrequest = I2C_GENERATE_START_WRITE;
Which at first sight has a repeated START condition for the next frame to transmit.
But from line 3473 the following code redefines xferrequest to I2C_NO_STARTSTOP:
if ((hi2c->PreviousState == I2C_STATE_MASTER_BUSY_TX) && \

        (IS_I2C_TRANSFER_OTHER_OPTIONS_REQUEST(XferOptions) == 0))

    {

      xferrequest = I2C_NO_STARTSTOP;

    }

So there is no RELOAD Bit set!

Thus the call I2C_TransferConfig() later will only set the AUTOEND Bit25 in I2C_CR2.  
Giving this situation with NO RELOAD Bit set and neither a START Bit set in the I2C_CR2 the cpu has a absolut correct reaction: Performing an immediate STOP condition, because there is obviously nothing to do…

As I stated above when the first HAL_I2C_Master_Sequential_Transmit_IT() with I2C_FIRST_AND_NEXT_FRAME is used everthing is fine for the second HAL_I2C_Master_Sequential_Transmit_IT():
There is a Reload Bit still kept in I2C_CR2 (from the first HAL_I2C_Master_Sequential_Transmit_IT()) and the CPU is happy to send the second frame.

So again my question: What is the usage of I2C_FIRST_FRAME?

Why is I2C_FIRST_FRAME not defined like
#define I2C_FIRST_FRAME        ((uint32_t)(I2C_RELOAD_MODE | I2C_SOFTEND_MODE))
for the F7?

This way nobody would have to spend hours of debugging and then I2C_FIRST_FRAME would have  had indeed the same behaviour on the F7 as the users know it from the F2

Best regards
Andy