HAL_FLASH_Program_IT and HAL_FLASH_EndOfOperationCallback

[santalint]

As HAL_FLASH_EndOfOperationCallback runs before __HAL_UNLOCK in HAL_FLASH_IRQHandler, when we know that the current operation has actually ended, it is not possible to initiate a new call to HAL_FLASH_Program_IT from the callback.

In other parts of the HAL it appears that __HAL_UNLOCK is done before callback in some cases, and I believe it is desirable to also do it in this case.

[RKOUSTM]

Hi @santalint,

Thank you for your contribution. We are actually aware about the point you raised out and are working on fixing it. The fix will be made available in the frame of a future release.

We cannot share a date for the moment. So stay tuned and thank you once more for your contribution and for your patience. We are looking forward to reading from you again.

With regards,

[ALABSTM]

Hi @santalint,

Back to this point you raised. If I understood correctly, you are referring the missing invocation of macro __HAL_UNLOCK() at the end of function HAL_FLASH_Program_IT() and that should be added before the return instruction shown in the code snippet below. Is this right?

https://github.com/STMicroelectronics/STM32CubeF4/blob/964d63294cab82f77c5a568ab3b4a9ea6c6d5a2a/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.c#L251-L253

Thanks,

[santalint]

I am not certain if the __HAL_UNLOCK() invokation should be in the function HAL_FLASH_Program_IT() or if it should be in HAL_FLASH_IRQHandler() HAL_FLASH_IRQHandler() does have a __HAL_UNLOCK() invokation, but no __HAL_LOCK(), and it is after the callbacks that are of relevance.

[ALABSTM]

Hi @santalint,

I hope you are fine. Back again to this request of yours. Have you tried to invoke the __HAL_UNLOCK() macro at the very beginning of the HAL_FLASH_EndOfOperationCallback()? Please keep me informed whether this solves the problem.

Moreover, to better understand your request, the HAL_FLASH_EndOfOperationCallback() is called from the HAL_FLASH_IRQHandler() in the cases listed below. Which one(s) do you need the callback to be called after the __HAL_UNLOCK() invocation?

1. A "sector erasure" operation has ended,

https://github.com/STMicroelectronics/STM32CubeF4/blob/d5af56388ff037735ac99de39abf2b46f9921aa3/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.c#L315

2. All "sector erasure" operations have ended,

https://github.com/STMicroelectronics/STM32CubeF4/blob/d5af56388ff037735ac99de39abf2b46f9921aa3/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.c#L333

3. A "mass erasure" operation has ended,

https://github.com/STMicroelectronics/STM32CubeF4/blob/d5af56388ff037735ac99de39abf2b46f9921aa3/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.c#L345

4. Program has ended

https://github.com/STMicroelectronics/STM32CubeF4/blob/d5af56388ff037735ac99de39abf2b46f9921aa3/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_flash.c#L351

With regards,

[tomteludd]

Hello, For case 1 above, I am uncertain if the HAL should be unlocked at that point. This is because it is only finished with one of multiple sectors.

For case 2, pFlash.ProcedureOnGoing = FLASH_PROC_NONE; is run, meaning the flash procedures has ended, and the value supplied to the callback indicates this as well. This happens before the callback.

For case 3 and 4, the same line can be found AFTER the callback, but there is nothing in the code explaining why it can't be set before.

For these three cases, as we KNOW that pFlash.ProcedureOnGoing is set to FLASH_PROC_NONE, there should not be any reason for the HAL to still be locked.

[ALABSTM]

ST Internal Reference: 165513

[RJMSTM]

Hello, I hope you are fine. The issue you reported has been fixed in the frame of version v1.28.1 of the STM32CubeF4 published recently on GitHub. Thank you again for having reported.

Regards,