STM32-NUCLEO-L432KC - I am able to detect my SD card, but not write to it.

[Raphael716]

LINK TO THE CODE

Hello everyone,

I'm working on a data logging project using a NUCLEO-L432KC board and a standard Micro-SD card module.

I have a very frustrating issue: Reading from the SD card works perfectly, but Writing fails immediately.

Hardware Setup:

• MCU: STM32L432KC (Nucleo-32 board)

• SD Module: Generic MicroSD Card Module (with 5V to 3.3V regulator and level shifter).

• Power: Module is powered via the 5V rail from the Nucleo. I added a 1000µF / 25V electrolytic capacitor in parallel on the breadboard to prevent any power drops (brown-outs) during write operations.

• Pinout: * SCK: PB3

  • MISO: PB4

  • MOSI: PA7

  • CS: PB6 (Software managed)

Software / CubeMX Setup:

• Library: FatFS R0.12c (via STM32CubeIDE).

• FatFS Config: _FS_READONLY = 0 (Disabled), _FS_LOCK = 0.

• SPI Config: MSB First, CPOL Low, CPHA 1 Edge, Baud Rate 125.0 Kbits/s for init.

• GPIO: SPI pins are set to "High" output speed.

The Problem:

My code successfully initializes the SD card. f_mount returns FR_OK, and f_getfree correctly reports the total and free space (approx. 1.18 GB).

However, when I try to write:

1. f_open works (FR_OK).

2. f_puts immediately returns EOF (-1).

3. f_sync fails with Error Code 9 (FR_INVALID_OBJECT).

Here is my debug log:

Plaintext

DEBUG: CMD0 sent. Reponse = 0x01
SD Card Mounted Successfully!!!
TotalSpace : 1185923072 bytes, FreeSpace = 1185906688 bytes
Writing data!!!
ERREUR: f_puts KO. sd card full or lock.
ERREUR CRITIQUE f_sync (9) : Voltage drop or spi crash.
Erreur fermeture fichier : (9)
Read Data :
            Closing File!!!

What I have already tried:

• Formatted the SD card to FAT32 (MBR) using the official SD Memory Card Formatter.

• Kept the SPI speed slow (SPI_Fast(); is commented out).

• Added the 1000µF capacitor to the 5V line.

My Question:

Some people suggested this could be a MISO line issue (missing pull-up resistor, or the 5V logic level shifter messing with the "Data Accepted" token during the write process). Since reading works, MISO works for general data, but maybe not for the write confirmation token?

Has anyone experienced this specific "Read OK / Write Fail" behavior with these 5V modules? Should I add a pull-up on PB4?

Any help would be greatly appreciated! Thank you.

More info:

[Raphael716]

I just tried to change SCK to PA5 and add pull-up on MISO, not working ...

[Ozone]

A SPI signal issue is unlikely to be the cause, or else reads would not work.
Although the current wiring does not support much more than the 125kBit you currently run it at.

> f_puts immediately returns EOF (-1).

The FatFS sources are part of the firmware, I would recomment to debug down into the HAL code, i.e. peripheral access functions to see what actually fails.
I'm not sure about the FatFS implementation, but all POSIX functions (like puts()/fputs()) which return -1 write an error code into the global "errno" variable. Check if this implemented, and what it contains.

You are aware that at least full-sized SD cards have a mechanical "write protection" switch, aren't you ?

[Raphael716]

Thanks for the inputs. Here is the latest status based on your suggestions and my debugging:

1. Signal Integrity & Speed: I am currently running at the slowest possible speed (Prescaler 256, approx 150kbps) to rule out wiring/signal quality issues. Reads are working perfectly at this speed (I can read the full file content).

2. f_puts/f_write behavior: I replaced f_puts with f_write to get better diagnostics.

   • f_write returns FR_OK and writes bytes to the RAM buffer correctly.

   • The error does not happen during the logical write.

3. The Actual Failure (f_sync): The blocking point is strictly during the physical write to the card.

   • When calling f_sync(&fil) (or f_close), the function returns Error 9 (FR_INVALID_OBJECT).

   • This happens even though the file object seems valid (since f_write just used it).

Hardware context:

• MicroSD (no mechanical write switch).

• Added a 100µF capacitor across VCC/GND near the module to handle write current spikes.

• Verified 5V supply to the module.

• MISO has a proper Pull-Up.

My question: Since f_write (RAM) works but f_sync (Hardware) fails with FR_INVALID_OBJECT, could this be a timeout issue in the low-level disk_ioctl (CTRL_SYNC) or disk_write function in user_diskio.c? It seems the STM32 loses the file handle context specifically when the card goes busy for the write cycle.

[Ozone]

To be honest, I never worked with a FatFS implementation involving Cube/HAL code.
However, I had got a SPL-based implementation for the F303 running, were I had to implement the "HAL" layer (physical SPI access) for FatFS myself.

In other words, I don't know how the Cube/HAL code is implemented - although what I had seen  often didn't impress me really.

Anyway, SD cards use a standardized protocol for physically access, with different bus modi. https://www.cactus-tech.com/wp-content/uploads/2019/03/An-Introduction-To-SD-Card-Interface.pdf
I would debug into this protocol layer, and see what the actual write/sync command returns on this level.
Often several similiar error returns get mapped into one more generic (and often very vague) generic error code in higher-level API functions.

[Raphael716 · Accepted solution]

Update: I just managed to fix the problem with the steel cage, I had an invisible memory bug on my global variables.