Report
3 years, 2 months ago.

Mounting SD card...failed!

Dear Neil,

after unsuccessful experiments with mbed's original SDFileSystem, I've read about yours (and your great effort writing it). However, as already stated above, I have not get it to work yet, either - maybe you or another reader has a suggestion. I'm using an LPC1768-based Ublox C027 with a SparkFun microSD shield and an Intenso SDHC Class10 card of 4GB formatted to FAT16 under Linux. The pins used are:

  • D8: CS (SSEL in Ublox' picture)
  • D11: MOSI
  • D12: MISO
  • D13: SCLK I've modified your example program to use that pinout, and to work without a button, which result in the message already mentioned above:

Mounting SD card...failed!

Here's what happens on the SPI: /media/uploads/guarndt/sdfilesystem.mountingfailed.png I hope that's readable, images seem to be scaled automatically here...the clock is shown twice, as D13 at the bottom, and as the blue analog signal in the middle. It is a little distorted, probably because of the cables to the oscilloscope, but I've tested the SPI to work in that configuration with an additional acceleration sensor connected, which works fine.

Do you think my configuration is wrong in some way, or maybe that the card is not supported by the lib? The SparkFun shield does not seem to have card detection, but the lib seems to handle that now. I've read a discussion about pull-ups to the data lines - what about those? I'm looking forward to any suggestion you guys have to offer, and I'll keep trying to get my paws on an older (smaller) SDcard in the meantime.

Question relating to:

A re-written SDFileSystem library with improved compatibility, CRC support, and card removal/replacement support. fatfilesystem, MMC, SD, SD Card, SDHC, SDXC
Comment on this question

3 Answers

2 years, 1 month ago.

Hi Gunnar, is there some progress on the problem now? If it is fixed, could you share some information on how you fix the SD problem? thank you very much!

I have a simular problem on the SDFileSystem in mbed. I am using the UBlox C027 and SparkFun CAN-Bus shield: https://learn.sparkfun.com/tutorials/can-bus-shield-hookup-guide The SD card is 8G, and it is in the microSD slot in SparkFun CAN-Bus shield.

The HelloWorld example for SDFileSystem Library is used and only the pins are changed. The pins I used were:

  • D9: CS (as descrbied Communication Methods in SparkFun CAN-Bus shield)
  • D11: MOSI
  • D12: MISO
  • D13: SCLK

The result output information is:

Hello World! Could not open file for write

I have no clue on where the problem is, any suggestions are welcome!

Hi Qing, sorry, no news on this topic from my side. I have switched to a Raspi as my development platform, and a Sitec S4 as my target platform. It uses the same radio hardware as the C027, but has a more powerful CPU and a 'proper' Linux OS. Things work fine here, but of course it is much more expensive.

posted by Gunnar Arndt 27 Mar 2017
3 years, 2 months ago.

How are you powering the SD card? If it's from the 3v3 connection on the edge of the C027 then that is the cause of your problems.

That pin is intended as a voltage reference rather than a source of power. With some small slow SD cards things will just about work but you'll get random file corruption. With anything else it simply doesn't work.

You need to either use an external 3.3V source or replace R21 (next to the 3V3 IO pin) with a 0 ohm resistor. If you do change the resistor then take care, shorting the 3V3 pin to ground will now blow up the power regulator.

The other gotcha on that board is that it must have both the USB and external power supply connected to function correctly. It is possible to remove the USB requirement but this involves a minor hardware change to the board.

Andy, thank you for the quick reply. The 3V3 pin is used indeed, as that is how the SparkFun shield is wired. However, there is another pin labelled IOREF (with the reset pin between the two), on which I measure 3.3V, whereas the 3V3 pin has less than 3.2V. Next thing is that I've already used that 3V3 pin to pull up the clock and data lines of an I²C bus, and to supply I²C sensors (with an agreeably low power requirement) successfully. So I'm wondering if you may have confused the 3V3 and IOREF pins?

Is it possible to just inject 3.3V from an additional converter to that pin, or would that cause trouble?

I know that an external power supply is required, as the board cannot even be flashed without one. I have one with 12V/1.5A, which should do the job. Your hint about the USB requirement, as I have to admit, got my attention. I'm planning to use the board standalone in a car, i.e. with a 12V supply only. According to my tests, it works without a USB connection. What hardware change do you think of?

posted by Gunnar Arndt 18 Mar 2016

If you check the schematic for the C027 (it's on the platforms page) there is a 33ohm resistor in series with the 3V3 pin (R21) and the IOREF pin (R20). The resistor is small enough that on average the voltage is good enough. However when there is a sudden current spike due to the SD card being active the voltage dips and the SD card crashes. In theory putting more capacitors next to the power pins of the SD card will fix the problem but when I was still having problems with 10uF there I decided it would be better to remove the resistor and replace it with a piece of wire. After that everything started working a lot better.

The 3.3V is generated by and LDO and they generally play nice if their output is driven by some other source. So yes, you should be safe to generate 3.3V from some other source and connect the two together. Having said that there is no real need to connect the two. Generate 3.3 on the shield from the 5V IO pin using an LDO and don't connect to the 3V3 pin at all and it'll work fine as long as the grounds are connected.

The 5V output doesn't have a resistor in series and so can be used for supplying power.

It works most of the time without the USB connection however you get some random crashes. They copied the LCP1768 design of having a separate semi-hosting CPU that connects to the main CPU via JTAG and serial. That second CPU handles the flashing and USB to serial interface and is only powered via USB but certain parts of the mbed library assume it's awake. The solution is to connect a schottky diode (something like a BAT60 or BAT54 will work fine, we don't need a lot of power) from the 5V IO pin to pin 1 of the USB connector (the VBUS pin). This way if the 5V rail generated from the power supply is on but there is no voltage from the USB cable the USB side of the board is powered from the power supply.

posted by Andy A 18 Mar 2016

Andy, thanks again for the details. Our electronics guy has shortcut R21 for me, but that didn't help. At least, I'm pretty sure now it's a software problem because the 3.3V line is stable (@3.16V) when trying to access the SD card - if the card drew too much current, the voltage would break down at some point.

posted by Gunnar Arndt 18 Mar 2016
3 years, 2 months ago.

I use a SD card without any problem with a 1768 BUT :
- there is a power regulator for the SD card
- this regulator has a switch, needed to reset the SD card (there is no reset line, you have to power off the card)
- near the card, there is a decoupling capacitor between the power and the ground (0.1µF)
- I use the nearly unchanged Mbed SDFileSystem
Do you use several SPI devices on the same SPI lines ? I use a LCD, Digital input and ADC : the only problem was the initialization sequence. First powercycling the SD card, then a file read to initialize the SD card and after this the other devices.
As the 1768 and the SD card are at the same logic level, the MOSI MISO SCLK are directly connected to the pins of the Mbed (short wires !)

A last remark : use the official SDCard formatter https://www.sdcard.org/downloads/formatter_4/ and not the Linux or Windows formatter.
As I use a linux computer, this formatter is in a VirtualBox virtual XP and the card is in a external USB card reader (this is needed to format the sd card from the virtual machine)

Robert, thank you for sharing your experience. I've checked the microSD shield, and found that it contains a 74HC4050D level shifter and some birdfeed next to the SD slot (some of which connects to the ground plane), so I guess that SparkFun have taken care of proper decoupling, too. That is something I just have to trust... However, there is no separate voltage regulator on the shield - it is connected to the host board 3V3 pin, as discussed in Andy's previous reply.

I had an acceleration sensor (ADXL345) connected to the SPI as well to isolate the problem, and found that it works fine. Considering your hint about short wires, I've just tested the SD shield without the oscilloscope connected, as it requires some longer wires. No change, though.

I'm going to test the SD card formatter as soon as I have a card reader here again.

EDIT: The formatter did not help - same problem.

posted by Gunnar Arndt 18 Mar 2016

To post an answer, please log in.