STM32F407G-DISC1 read SD Card problems

[James Jacobs]

Posted on February 03, 2017 at 13:38

We have a problem using STM32F407G-DISC1.

We have a custom PCB that mates with the DISC1 board. The PCB has an SD Card slot wired to SPI1 on the DISC1. We have tried a number of DISC1 boards about 50% of them are able to read the SD card about 50% are not (fail to mount) (of about 30 DISC1 boards).

We have tried many things to discover the source of this problem but can not pin it down to a single source - I've listed what we have tried below.

We've used DISC0 before (about 10 boards) and not seen this problem.

One thing that we can't understand that seems to make a difference is touching some pins on the DISC1 with your finger (PE1, PE2, PE3, PE4) - these are unconnected pins that have been set as output pull-up (we've also tried analog input). This effect seems to be present whatever else we try.

Things we've tried. Decoupling caps 3V-GND on SD card pins, pull-up 10k resistors on SPI (MISO, MOSI, CLK), unused pins to input, pullup, unused pins to analog, checked SPI lines on oscilloscope (0-3V swing, ~5ns rise time), repeated reprogrammed DISC1 board, different SD cards, software delay after power before read SD, NVIC_reset after failed SD card reads, cleaned PCB, changed ABP2 divider and SPI prescaler to get different SPI clock speeds - plus many variations on these behavior is always the same.

#stm32f4-discovery #sd-card #stm32

[Tesla DeLorean]

Posted on February 03, 2017 at 15:17

Ok, but does the SPI-SD provide any insight into the nature of the failure, or a break-down of the protocol?

The placing of hands often means a grounding issue. Are the grounds in the system all bonded at multiple points?

Perhaps you can diagram the circuit and the board fixturing?

Have you tried driving the pins less aggressively? ie dropping slew rate from 100/50 MHz to 25 MHz or below?

Do the DISC1 boards have current ST-LINK firmware? Use the ST-LINK Utilities to update, the shipped version had mbed hold the boards in reset and precluded them from being powered from USB chargers. I don't suspect it is the issue at play here, but lets at least pull one of the jokers from the pack.

[James Jacobs · Accepted solution]

Posted on February 03, 2017 at 21:41

We solved this problem. The clue lay with the pins that touching with a finger remedied the problem.

PE3 is the chip select for the on-board MEMS device. The MEMS also uses SPI1 so was obviously interfering with the SPI with the SD Card. Holding PE3 pin high removed the problem, we did this in software but it also worked externally.

It appears a finger must been providing enough potential to momentarily turn the pin on and disable the MEMS. I'm not sure why setting all un-used pins as pullup didn't affect this.

Lesson is, check what other functions the pins you are using have and where they are connected.