STMicroelectronics/STM32CubeL4

TX IRQ remains active after HAL_I2C_Mem_Read_DMA

accabog opened this issue · 5 comments

Because HAL_I2C_Mem_Read_DMA MemAddress transmission is based on TX IRQ

I2C_Enable_IRQ(hi2c, I2C_XFER_TX_IT);

neither I2C_Mem_ISR_DMA nor I2C_ITMasterCplt will not disable the TX IRQ after the data transfer

I2C_Disable_IRQ(hi2c, I2C_XFER_RX_IT);

Therefore, if a non-IT based transmission such as HAL_I2C_Mem_Write will follow, a TX irq will be triggered without any interrupt callback defined, therefore the IRQ cannot be cleared and results in the program stuck in I2C ISR

Hello @accabog ,
First of all, thank you for this contribution.
Would you please give us more details about how you got this issue? Did you observe it at runtime? If so, could you please share the code you have used to reproduce the problem.

Best Regards,

Hello @HBOSTM ,

To reproduce, try a HAL_I2C_Mem_Read_DMA and after that do HAL_I2C_Mem_Write.
The HAL_I2C_Mem_Write will trigger a TX IRQ, even though it should not.

HAL_I2C_Mem_Read_DMA enables I2C_XFER_TX_IT when called and disables only I2C_XFER_RX_IT in I2C_ITMasterCplt.

I've encountered this situation when I called HAL_I2C_Mem_Read_DMA and after that called HAL_I2C_Mem_Write.
Got stuck in ISR because hi2c->XferISR had not been set.

Hello @accabog ,

thank you again for this contribution.
This point has been reported to our development teams. I will get back to you as soon as I have any updates.

With Regards,

ST Internal Reference: 145679

HBOSTM commented

Hello @accabog

The fix you requested has been implemented and is now available in the frame of the latest stm32l4_hal_driver package V1.18.0 release. This issue can be closed now. Thank you again for your contribution.

Best Regards,