SparkFun Thing Plus - STM32: SD Card FR_NOT_READY in STM32IDE

Development Boards
1

Hello!

I am trying to program a SparkFun Thing Plus - STM32 board to write to an SD card using the integrated SD card breakout.

However, I keep encountering the FR_NOT_READY error when attempting to mount the card using the FATFS middleware.

Setup Details:

IDE/Tools: STM32CubeIDE with FATFS middleware and SDIO configured in a 4-bit wide bus.
Voltage: The SD card breakout is powered by 3.3V, which should be sufficient for my SD card (onn. 64GB Class 10 U3 MicroSDXC).
Detect Pin: From my understanding, this package does not have a Detect_SDIO pin.

Current Initialization Code:
int init_sd_card(void) {
res = f_mount(&fs, SDPath, 1);
if (res != FR_OK) {
printf(“SD card mount failed with error: %d\n”, res);
return 0;
}
printf(“SD card mounted successfully.\n”);
return 1;
}

Observations:

Debugging with a SEGGER J-Link shows the following values for SDPath (decimal representation):
[0] = 48, [1] = 58, [2] = 57, [3] = 0
The issue seems to originate in disk_initialize (inside diskio.c), which returns 1. This propagates to ff.c, causing the FR_NOT_READY error.
If I set the SDIO up as being 1-bit wide, then I make it further in the chain, where stat will be RES_OK, and the init function fails because of the error FR_DISK_ERR

Questions:

  1. Could the lack of a Detect_SDIO pin be causing this issue? If so, what workarounds are recommended?
  2. Could this be related to power or timing issues on the SDIO lines?
  3. Are there any additional debug steps or configurations I should check to identify the problem?
  4. Any solutions or experience?

Any advice or insights would be greatly appreciated. Thank you!

EDIT: When I run it in 1-bit wide SD, it will fully work when the clock is scaled down sufficiently. 8MHz is too fast, with a prescaler of 9 (1.45MHz) it works, 8 though is too fast

2

Since thi8s is getting stale I tossed it @ perplexity and it has some decent suggestions…some are irrelevant (you mentioned SD cards specs, for instance…so that suggestion doesn’t apply) but most of the others seem good (largely focused on ensuring signal integrity)