SdFat works with 256MB, but not with 4GB SDHC

Hi, my setup is maple mini clocked to 128Mhz,
SPI(1) is driven by clock interrupt, feeding sregs and DACs.
SPI(2) is feeding OLED and SD in the loop.

I started with 250MB plain SD formated to FAT32, 1024 Allocation unit size, works great.
4GB cards Formated to FAT32,16 any unit size, different SPI prescalers….begin(); does not even return true. (2 brand new SD cards);
Known-good formated SD pulled forom Grandpa EURORACK module (Arduino and SD.h) does not work.

Any clue?

The smaller the SDcard the faster. Try to decrease the clocks.
Start at 72MHz main clock and 9-18MHz SPI for the SDcard.

Formatting an SD for any embedded device should be done with the official SD formatter: HERE
Do this even with new cards to establish a baseline.

With SD, breadboarding can be problematic, even small breadboard with short jumpers can introduce enough impedance shift that the card can simply refuse to work correctly. If you absolutely must mount an SD reader, be certain to keep all wiring minimal and to cleanly solder the connections leading back to the uC. IMO, overclocking will simply add to the SD woes on embedded systems and I strongly suggest to not do it.

Capacity chart is here.

Ray

you are using greiman’s sd fat?
https://github.com/greiman/SdFat
, there are some examples such as reading sd info
https://github.com/greiman/SdFat/tree/m … les/SdInfo
it may be worth trying them out as if sdinfo don’t work the problem may be connectivity itself (e.g. SPI speeds etc)
if connectivity is good then next would be figuring out other things like FAT format etc
i’ve been using an 8 GB micro sd card on spi2 and it seemed it works, i’m using the default 72 mhz
initialization looked something like this, pretty much derived from the examples
// Initialize at the highest speed supported by the board that is
// not over 50 MHz. Try a lower speed if SPI errors occur.
if (!sd.begin(chipSelectpin, SD_SCK_MHZ(50))) {
sd.initErrorHalt();
}


Tahnk you. I changed to 72Mhz, cards were already formated by official SdFormater.

[ag123 – Sun Jan 21, 2018 3:33 pm] –
it may be worth trying them out as if sdinfo don’t work the problem may be connectivity itself (e.g. SPI speeds etc)
if connectivity is good then next would be figuring out other things like FAT format etc
i’ve been using an 8 GB micro sd card on spi2 and it seemed it works, i’m using the default 72 mhz
initialization looked something like this, pretty much derived from the examples

I drive display from same port with DMA and dual buffer, but before acessing SD, it waits for it to finish.
After adding error output, Serial spits on me this.
Can't access SD card. Do not reformat.
SD errorCode: 0X43,0X5


BTW, I just pulled 16GB one out from the old phone and it works without formating on 64MHZ SPI clock-no problem.

i’m pretty much a novice in sd cards technology as well, i think the clue to that may well be in the SD simplified specs
https://www.sdcard.org/downloads/pls/
in particular Part 1 Simplified Physical Layer Simplified Specification
section 4.7.4 list the various detailed command description starting p.86
section 4.9 responses detailed the responses starting p.98
the responses are apparently related to the SDIO commands as different commands has different response formats

however, it seem to suggest that it has something to do with the *card* itself rather than anything to do with FAT format on the card.
your last response on the 16gb card seemed to confirm it

section 4.10.1 card status starting p101
i’m making a wild guess, it is supposed to be a 32 bit field, but that the response has only the lower 16 bits
assuming the fist byte being the lowest byte
0X43,0X5
0x43 ~ 0100 0011
first 2 bits is reserved so the 3 is unknown
the 7th bit – event invoked
0x05 ~ 0000 0101
bit 0 – ready for data
bit 3 – erase reset – an erase sequence was cleared before executing because an out of erase sequence command was received

this would be a little strange as it seemed sdfat is trying to write something to the card when it is initializing
———-
note one of those things may well be *bad or loose contacts*, i’m not too sure if sdfat is trying to write something to the card to detect if a card is present

0x43 is the code for SD_CARD_ERROR_ACMD41.
https://github.com/greiman/SdFat/blob/e … Info.h#L71
I would post the issue on Greiman github page.

I recreated the setup on the breadboard and clean software and 4GB SD WORKS(problematic setup is prototype PCB) .
I am pretty sure, that settings of SPI and DMA registers during begin() function don’t completly override settings created by display.

Now, after disabling all display communication 4GB SD WORKS!!
Still don’t consider it solved till I track down SPI.setting responsible for not accepting one type of card and noproblem talking with others.

Note of caution, the SPI1 port is not supposed to run that fast.
While testing something I had loads of errors with an SD card.
I decided to test the SPI port alone, and connected TX to RX, then did DMA transfers. The result is that at max speed, with DMA for TX and RX, and someone else doing memory access (CPU or other DMAs), sometimes you have a buffer overrun and lose an RX byte. I was able to catch by both sending a buffer and comparing what I get in RX with what I sent in TX at the end, and by using the debugger and looking at the registers.
Since the MCU specs claim the ports can run at a maximum of 18Mbps, and I didn’t have the problem at that speed, I didn’t do any more testing to try to find a way to avoid it. I did test changing the priority of the RX DMA channel to the highest, and did not solve the issue.

Try the exact same setup you have failing, but slow the port to DIV4 or DIV8 and see if it works. If you need a faster transfer from sdcard, often times is better to get a better card with less latency and run the SPI at a lower speed, than just increasing the SPI speed in a slow card, since the card will just add more latency to have time to process.

The most common cause of this symptom is a missing pull up resistor on DO of the card.