CubeMX/CubeMXIDE F469I-Disco board generates incomplete SDIO code in main.c Latest versions, code sets hds1.init variables then ends section. MX_SDMMC1_SD_Init never calls anything. What's going on?

[Harvey White]

Have tried with earlier versions of CubeMX, different computer. Does the same thing. Do not see any use of the init structure (which is local). SD card is not initialized properly.

Complete code generated is:

tatic void MX_SDMMC1_SD_Init(void)
{
 
  /* USER CODE BEGIN SDMMC1_Init 0 */
 
  /* USER CODE END SDMMC1_Init 0 */
 
  /* USER CODE BEGIN SDMMC1_Init 1 */
 
  /* USER CODE END SDMMC1_Init 1 */
  hsd1.Instance = SDMMC1;
  hsd1.Init.ClockEdge = SDMMC_CLOCK_EDGE_RISING;
  hsd1.Init.ClockBypass = SDMMC_CLOCK_BYPASS_DISABLE;
  hsd1.Init.ClockPowerSave = SDMMC_CLOCK_POWER_SAVE_DISABLE;
  hsd1.Init.BusWide = SDMMC_BUS_WIDE_1B;
  hsd1.Init.HardwareFlowControl = SDMMC_HARDWARE_FLOW_CONTROL_DISABLE;
  hsd1.Init.ClockDiv = 0;
  /* USER CODE BEGIN SDMMC1_Init 2 */
 
  /* USER CODE END SDMMC1_Init 2 */
 
}
 

This seems incomplete to me. Trying to compare this code with the BSP driver code indicates that more code is needed somewhere.

If there's a setting that I'm missing, I'd like to know it. Earlier versions (circa 2018) do the same, so something is missing. FATFS is enabled, SDIO has more or less appropriate parameters.

[TDK]

HAL_SD_Init is called when the disk is mounted.

f_mount() -> find_volume() -> SD_initialize() -> BSP_SD_Init() -> HAL_SD_Init()

[Harvey White]

OK, so the code generated in the MX_SDMMC1_SD_Init section is useless?

That means that the entire SDIO init sequence is elsewhere (which you said....)

Did you pull the code sequence from the BSP demo code or did you go through CubeMX_IDE?

The IDE code seems to have a lot of indirection to make it "universal". Been trying to get it to work and just about ready to pirate the code from the Disco Demo.

[TDK · Accepted solution]

It’s not useless. It initializes the handle. The handle is global.
I used code as generated by CubeMX from a default project.
Yes, tons of redirection/obfuscation when dealing with low level SD drivers on top of generalized HAL code on top of FatFS which is obfuscated itself. It’s unfortunate, but that’s the norm with C libraries.

[Harvey White]

Ok, missed the handle being global. The code certainly doesn't work the way that other subsystem inits work.

Essentially, then, the way to get this to work is (once it compiles, and that changes with how you decide to structure the disk access functions), initialize only what you need to access the resource, do no initialization on the hardware itself. (I needed to install a global semaphore to control access).

DO NOT do anything to try to install the SD card other than

			fresult = Disk.mount(&Disk.FatFs, "0:", 1); //1=mount now
 

In my case, Disk is a C++ class, and Disk.mount is the same as calling the f_mount function. Since all of my control structures are in C++, and I'm also using a packet method of control for mesh networking, it makes sense.

For anyone else not going such a complicated method, the f_mount link with the same parameters is in ff.c if you want direct access.

NOTES: not all card file systems are supported, so try a smaller card that doesn't use exFAT or the equivalent.

Not all cards run at all clock speeds, so that's something.

The card must be installed, which means detected (which means that there's a card present pin) to be initialized. Otherwise, initialization fails

Got it working.

Thanks for the help