HAL_FMPI2C_Mem_Read_IT() in library "stm32f4xx_hal_fmpi2c.c" claims to be "Read an amount of data in non-blocking mode with Interrupt", yet behaves as a blocking call. Where am I going wrong?

[Mike xx]

My understanding of a non-blocking function is that the function will return immediately, and it is up to you to use a callback or other method to collect the data. With FreeRTOS it's not difficult.

Yet HAL_FMPI2C_Mem_Read_IT() seems to hang around and reply with a HAL_OK if a device acknowledged the device address or a HAL_ERROR if no Ack is received.

This isn’t the behaviour I expected, and expected a HAL_OK independent of the device responding.

[Foued_KH]

Hello @Community member​ ,

• Blocking Mode:

The communication is performed in polling mode. The status of all data processing is returned by the same function after finishing transfer.

• Non-blocking modes

The communication is performed using Interrupts or DMA. These functions return the status of the transfer startup.

The end of the data processing will be indicated through the dedicated I2C IRQ when using Interrupt mode or the DMA IRQ when using DMA mode.

This function HAL_FMPI2C_Mem_Read_IT()  reply HAL_ERROR if no device on the bus or if no ACK is received.

 

Foued

[Mike xx]

I am aware of the definitions. I have checked the function HAL_I2C_Mem_Read_IT() by setting a pin high before entering, and low after exiting the function.

A, I2C read operation is of 2 parts. The first is a Write, comprising the device address and the subaddress, after that is a repeated read and the device should respond with data.

Until the Ack is received in the first write part of the transaction, the task is blocked.

HAL_I2C_Mem_Read_IT() claims to be non-blocking, but that isn't entirely true; where the write aspect is blocking. It conveniently returns an HAL_Error if a NAK is returned after the write aspect.

Without a status callback indicating an error such as a NAK after the first Write I guess someone has considered this a compromise.