search

STMicroelectronics / STM32CubeF1

STM32Cube MCU Full Package for the STM32F1 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
521 stars 173 forks source link

HardFault in I2C_DMAXferCplt #6

Closed mdmikh closed 4 years ago

mdmikh commented 5 years ago

I2C tx data transfer initiated by HAL_I2C_Mem_Write_DMA completes with HardFault in I2C_DMAXferCplt routine if rx DMA is not configured before.

The issue is with possible NULL pointer hi2c->hdmatx or hi2c->hdmarx dereference in routines I2C_DMAXferCplt, I2C_DMAError, I2C_DMAAbort.

In case when only RX DMA or TX DMA is used and configured the following code breaks because only one pointer is set:

/ Clear Complete callback /

hi2c->hdmatx->XferCpltCallback = NULL;

hi2c->hdmarx->XferCpltCallback = NULL;

ALABSTM commented 5 years ago

Hi Dmitry,

First of all, thank you for having pointed out this issue. It will be transferred to our development teams to check its relevancy.

We will be back to you as soon as we get an answer. Thank you for your patience, and for your contribution once more.

With regards,

ALABSTM commented 5 years ago

Hi Dmitry,

Would you please indicate the FW version which you spotted this issue on? Are you using the latest FW version (v1.8.0)? Thank you for your answer.

With regards,

mdmikh commented 5 years ago

The issue was found on v1.8.0. Previous version v1.7.0 has no such error as clear callback code was added later.

The fix is trivial:

/ Clear Complete callback / if (hi2c->hdmatx != NULL) { hi2c->hdmatx->XferCpltCallback = NULL; } if (hi2c->hdmarx != NULL) { hi2c->hdmarx->XferCpltCallback = NULL; }

Affected routines I2C_DMAXferCplt, I2C_DMAError and I2C_DMAAbort

ALABSTM commented 5 years ago

Hi Dmitry,

Thank you for this precision. I will refer it to our development teams so they look closer into it.

With regards,

ALABSTM commented 5 years ago

Hi Dmitry,

Our development teams confirmed the issue you pointed out. A fix will be officially published in the frame of a future release. We cannot commit on a precise date for the moment. However, we hope it will be soon enough.

We will try to provide you with a patch as soon the fix is implemented from our side. In the meanwhile, you can implement, from your side, the solution you suggested. Thank you once more for this contribution.

With regards,

ALABSTM commented 5 years ago

ST Internal Reference: 75370

ALABSTM commented 4 years ago

Hi Dmitry,

A fix has been implemented. It will be published within version 1.24.2 of STM32CubeF4 firmware package, which will be released soon.

This same fix apply to the F1 firmware. However, for this latter, we cannot share a date for the moment.

The fix consist in the replacement of the two lines shown below...

-  hi2c->hdmatx->XferCpltCallback = NULL;
-  hi2c->hdmarx->XferCpltCallback = NULL;
+  if (hi2c->hdmatx != NULL)
+  {
+    hi2c->hdmatx->XferCpltCallback = NULL;
+  }
+  if (hi2c->hdmarx != NULL)
+  {
+    hi2c->hdmarx->XferCpltCallback = NULL;
+  }

... in the list of functions listed here: https://github.com/STMicroelectronics/STM32CubeF1/blob/441b2cbdc25aa50437a59c4bffe22b88e78942c9/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c#L6648 https://github.com/STMicroelectronics/STM32CubeF1/blob/441b2cbdc25aa50437a59c4bffe22b88e78942c9/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c#L6780 https://github.com/STMicroelectronics/STM32CubeF1/blob/441b2cbdc25aa50437a59c4bffe22b88e78942c9/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_i2c.c#L6809 Note that for the case of the I2C_DMAAbort() function, you have to replace these two lines too:

-  hi2c->hdmatx->XferAbortCallback = NULL;
-  hi2c->hdmarx->XferAbortCallback = NULL;
+  if (hi2c->hdmatx != NULL)
+  {
+    hi2c->hdmatx->XferAbortCallback = NULL;
+  }
+  if (hi2c->hdmarx != NULL)
+  {
+    hi2c->hdmarx->XferAbortCallback = NULL;
+  }

I hope this helps. Thank you once more for this contribution. If you have no other question about the subject, I think this issue can be closed now.

With regards,

ALABSTM commented 4 years ago

Hi Dmitry,

We hope you are doing well. STM32CubeF4 v1.24.2 firmware package has been released two weeks ago. You can find the above described fix implemented within. This issue can be closed now.

With regards,

SpyrosMourelatos commented 4 years ago

For real , you closed an issue because you patched it in an other irrelevant repository ,without patching it here ? You really owe my boss my daily wage multiplied by 2

Phisik commented 4 years ago

STM32CubeF4 v1.24.2 firmware package has been released two weeks ago. You can find the above described fix implemented within.

Have you patched only STM32CubeF4??? I have faced exactly the same issued with STM32F103. I have the latest update of CubeIDE available on 2020-04-13. And the problem still exists!

STM32CubeIDE Version: 1.3.0 Build: 5720_20200220_1053 (UTC)

ALABSTM commented 4 years ago

Hi @DrunkenMastah, hi @Phisik,

The new F1 series' firmware has not been released yet and will not be in the near future. Unfortunately, we cannot share a date for the moment.

In the meanwhile, the fix released for the F4 series also applies to the F1. Users could port it to the F1 driver and avoid remaining stuck due to this bug. This is why we notified the STM32CubeF4 v1.24.2 publication here. This is also why we considered the issue as solved and closed it.

Regarding CubeIDE and CubeMX, both use the currently available F1 series' driver. As this latter does not implement the fix, users will face the same issue.

We will do our best to publish the new STM32CubeF1 firmware as soon as possible. We count on your patience and comprehension.

Thank you,

cl-wi commented 4 years ago

Same problem in F0 FW.