Please Correct BUG with SD code generation

[cavizzano9]

Posted on March 02, 2017 at 18:57

The new format of code generation makes a BUG in the file: bsp_driver_sd.h

The BUG prevent building FAT_FS modules

To solve the issue line 67 should be changed with the following ones:

&sharpifndef BSP_SD_CardInfo

  &sharpdefine BSP_SD_CardInfo HAL_SD_CardInfoTypedef  &sharpdefine SD_CardInfo HAL_SD_CardInfoTypedef&sharpendif?

DETAILS: there was a typo in the first define (capital vs small cap Typedef vs TypeDef)

The second define is the one required by sd_diskio.c

...Middlewares/Third_Party/FatFs/src/drivers/sd_diskio.c:161:3: error: unknown type name 'SD_CardInfo'

   SD_CardInfo CardInfo;

This is an error in code generation (e.g. cube program) and not the library files and there is no way to rollback after an update (very annoying).  Any help in solving this issue faster is appreciated.

C.Alberto Avizzano

#endif

[Imen.D]

Posted on March 03, 2017 at 09:13

Hi,

Could you please precise in which HAL library you have found this issue? So, we can verify it.

Thanks

Imen

[cavizzano9]

Posted on March 03, 2017 at 11:17

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.

[Hans Jonker]

Posted on March 13, 2017 at 09:32

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.

[rpflughoeft]

Posted on March 20, 2017 at 17:05

I'm having the same problem. Have you seen any resolution?

[Hans Jonker]

Posted on March 21, 2017 at 07:20

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.

[Marco1]

Posted on March 23, 2017 at 16:13

Same problem !

[Marco1]

Posted on March 23, 2017 at 16:14

Upgrade 'c0ck of dog version' ! Italian transaltion 

[misagh]

Posted on April 09, 2017 at 12:40

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?

Thanks,

Misagh

[rpflughoeft]

Posted on April 10, 2017 at 05:33

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).