Could you please precise in which HAL library you have found this issue? So, we can verify it.
The errors appears when migrating the STM32CUBE version to the last one (4.19).
Tested Package library STM32F7 Version 1.6.0.
However, the problem does not seems to be strictly related to the library version.
The code generation was properly working with previous versions (tested 4.14, 4.16) The error appeared when we migrated to the last cube version. The error is not strictly related to the libraries themselves but in the interface code generation with third party middleware (FATFS).
The two additional lines in the post above will solve the issue.
I hope this can help.
Last Friday I updated to Cube 4.20, library L4_V1.7.0.
Migrated a project I'm working on, and tried to compile. Unfortunately, I encountered numerous errors in
bsp_driver_sd.c and bsp_driver_sd.h
Apparantly the *hal_sd (.c/.h) changed a number of functions which where not reflected in the bsp_driver files.
To name a number:
a) HAL_SD_TransferStateTypedef BSP_SD_GetStatus(void)
Cannot find definition of HAL_SD_TransferStateTypedef
The function itself calls for the function HAL_SD_GetStatus, for which I cannot find a prototype either, so no clue on what the return type should be. Since this function seems not to called anywhere (I did not use the SD card in this project YET!) for now I commented both the prototype and the function itself.
b) void BSP_SD_GetCardInfo(HAL_SD_CardInfoTypedef *CardInfo) should be ...TypeDef.... This change in casing happens on more locations.
c) At several places the function return value is checked against SD_OK, whereas this seems to have changed to HAL_OK.
d) HAL_SD_WideBusOperation_Config seems to be renamed to HAL_SD_ConfigWideBusOperation
e) HAL_SD_Init no longer takes 2 parameter, it only takes 1
f) HAL_SD_ReadBlocks_DMA no longer takes the parameter BlockSize, where the HAL_SD_ReadBlocks (non DMA) no longer takes a BlockSize but instead takes a timeout. The same applies to HAL_SD_WriteBlocks_DMA. This means that the functions like BSP_SD_ReadBlocks should have changed their calling parameters as well..
In addition, there is quite a number of warnings on incompatible pointer usage.
Now I DO appreciate the amount work STM has put into CUBE_MX but, and I do realise bugs can slip by, but this is a biggy.
PLEASE, PLEASE consider a way to use previous versions of Cube_MX (NOT the library, I figured that out!)
For that is the main reason I am upset with above bugs. Once I change Cube_MX, I cannot revert to an older version. YES, I can revert to using a previous library version, but that does NOT provide us with a complete return path. There are still changes in the generated code...
EDIT: The issue in bsp_driver.c .h seemt to origin in the 'USER CODE BEGIN/END construct. It appears that almost all of the code is marked as 'user code' even though it is VERY closely related to interfacing with the other library files.
I'm having the same problem. Have you seen any resolution?
No, I have not. What I suggested in my edit: the user code begin/end seem to be inverted. If you can manually extract what you added yourself, you then throw away bsp_driver.c (.h) and regenerate the code. That way a fresh file is genererated, which DOES compile. Then add your own code again.
Not the nicest way of working, but for me it worked.
Same problem !
Upgrade "c0ck of dog version" ! Italian transaltion
I have the same problem. After updating the bsp_driver_sd.c and .h by code generator, the BSP_SD_ReadBlocks_DMA() and BSP_SD_WriteBlocks_DMA() doesn't work properly. Any idea?
In my situation, I just gave up on trying to use the update and locked in on my the existing code that Cube had generated. Since I'm not changing any base functionality in the I/O, I'm ok. But it would have been nice to have the option of using the newest version (without having to go through the steps that Jonker.hans did).
Thank you for your reply. After 2 days, Finally I found the problem. For efficiency reasons, ST deleted the checking SD status after reading/writing data from/to SD by DMA, and leave that to us to implement our own checking code. So in my code, I waited for DMA transfer complete interrupt after read/write by DMA, and it worked!!! Now my code is more efficient while I'm using FreeRTOS and used OS signals to suspend the current task.
After all, I was expecting ST to write at least an example code or something like that (even not efficient) to give us an idea. It was really confusing.
Could you tell me where you added that code or it will be nice if you can send your code for DMA.
This is my email: email@example.com
For a week I try to run DMA in my SD card and nothing work
Thanks for highlighting this issue and sorry for the inconvenience it causes.
The fix for this issue will be available in CubeMX4.21 that will come very soon.
Please upgrade your CubeMX release as soon as CubeMX4.21 is available.
Hello ST team
I'm working with
I'm writing to you because I'm working on STM32F746ZGTx, but I have found the same BUG problem with the SD card in CubeMx version 4.23.0 library Firmware package STM32F7 v1.8.0.
Before I was working with CubeMX 4.21.0 and Firmware Package 1.7.0 and the problem with the SD card was solved, now I updated with the new version 4.23.0 and seems the .h and .c files have a lot of changes (for instance stm32f7xx_hal_sd.c )
Please, could you fix the issues?