Null pointer check needed in HAL_I2C_Mem_Write_DMA

[iforce2d]

(STM32Cube_FW_F1_V1.8.2/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c)

In HAL_I2C_Mem_Write_DMA, hi2c->hdmarx may be null but this is not being checked. This causes a crash when invoking HAL_DMA_Abort_IT if there is no DMA used for receiving.

btw is there a better place to report this?

Also, does anyone know why this website is so incredibly slow?

[Imen.D]

Hello @iforce2d​ ,

Thank you for your contribution.

I will check this reported issue and come back to you soon with update.

What do you means please : "this website is so incredibly slow?" Do you have a problem to connect on the Community ?

Imen

[Imen.D]

Hello @iforce2d​ ,

Basically it was introduced due to the implementation of the "callback registration" mechanism.

Even a hardfault might occurs when only RX DMA or TX DMA is used and configured. So the issue is with possible NULL pointer hi2c->hdmatx or hi2c->hdmarx in routines I2C_DMAXferCplt, I2C_DMAError, I2C_DMAAbort.

So, the idea was to update I2C_DMAXferCplt(), I2C_DMAError() and I2C_DMAAbort() APIs when hdmatx and hdmarx parameters in i2c handle aren't initialized (NULL pointer) by adding a check on hi2c->hdmtx and hi2c->hdmarx before resetting DMA Tx/Rx complete callbacks.

This was already fixed and integrated in STM32CubeF1V1.8.1.

Please select my answer as Best if satisfy your need, so that this thread will marked as solved.

Imen

[Imen.D]

Hi @iforce2d​ ,

You're right, after more check and investigate, I confirm that there's a typo here:

/* Abort the ongoing DMA */

dmaxferstatus = HAL_DMA_Abort_IT(hi2c->hdmarx);

It should be hdmatx as some code after we check hdmatx value.

This issue will be fixed in the impacted families: STM32F1, STM32F2, STM32F4 and STM32L1.

Thanks you for your contribution and reported issue.

Imen