SDIO demo code doesn't work with uSD ver. 1?

Dave Jones · ‎2017-03-14

Posted on March 14, 2017 at 19:51

I have an STM32L476G-EVAL board and the STM32L4 firmware package. I took their application demo for FatFs which uses the SDIO interface and formats the uSD card, then writes a text file to it, then reads it, then sits in a loop, and I modified it. I changed it so it doesn't format the card. It simply reads the names of the files on the card and displays them on the LCD on the Eval board.

This works fine with HC uSD cards (greater than 2GB, FAT32). But it fails when I use uSD cards that are smaller non-HC cards (less than 2GB, FAT16). They are version 1 of the SD spec, as opposed to version 2 which the HC and above use. I tried with a 1GB card and a 1/2 GB card.

It looks like the HAL SD init code is wrongly identifying them as MMC cards and returning 'invalid drive'. They certainly are not MMC cards. They are uSD cards and clearly say SD on them.

I have another board, using a PIC24 and using SPI to talk to the cards, and using code libraries written by Microchip. That board has no problem reading the filenames off of any of the uSD cards I have, including all of the version 1 cards (the small ones). But the STM32 code is only working with the HC cards and failing with the smaller sized cards.

Has anybody else run into this? Does anybody know where the problem is, and know of a fix?

If you have a board working with the demo code or maybe with MX generated code, have you tested it with a uSD card less than 2GB? If not, do you happen to have one available to try it and see if it fails? My guess is that whoever wrote the L4 demo code, or the base code in the MX generator, was only testing using larger cards, since that's pretty much all you can buy in most places these days. You have to dig around on Amazon to even find the older smaller cards now.

Tesla DeLorean · ‎2017-03-14

Posted on March 14, 2017 at 20:57

>>Has anybody else run into this?

They have a decade of experience writing poor untested code for mass storage block devices. I've ceased being surprised.

As I recall the older standard uses different commands, with byte rather than block offsets. The identification code should be able to make a determination about the version and capacity of the card, and the IO code pick a command and block size setting to accommodate that.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Nemui Trinomius · ‎2017-03-14

Posted on March 15, 2017 at 01:18

Dear Dave Jones,

Currently many STM32 HAL libraries doesn't support SDv1 and MultiMediaCards.

You may need to make SDv1,MMC, and eMMC support by yourself.

See below thread more detail.

https://community.st.com/0D50X00009Xkg1RSAR

Best Regards,

Nemui.

Dave Jones · ‎2017-03-16

Posted on March 16, 2017 at 21:11

OK, I haven't solved it, but I have found a clue as to what is going on.

I traced the problem to the SD_PowerON() function. When it sends CMD55 (APP_CMD) it returns 'illegal command'. But that command is a legal command in all SD cards. I have a copy of the simplified 1.0, 1.1, and 2.0 SD specs and it was a mandatory command in all of them. These are microSD cards, marked with 'SD' on them so are clearly not MMC cards. So they must support the CMD55. They are probably v 1.0 or 1.1 since they are 1GB and 512MB.

Just before sending the CMD55 in the PowerON() function it sends CMD8 which, if it gets a good response, shows that it is an HC microSD card as opposed to a standard one. But CMD8 is an illegal command in the standard (ver. 1) cards.

So I commented out the code that sends the CMD 8 (and it's response). Now it works. The CMD55 works. As do the rest of the commands initializing the card. And so does the rest of my code reading and displaying the file names of the files in the directory on the card.

So something about sending that CMD8, illegal command, before sending the CMD55 is causing the issue. There must be some kind of error code or status that is not getting cleared between the two.

Anybody know this SDMMC device well enough to hazard a guess what is going on???

Dave Jones · ‎2017-03-16

Posted on March 16, 2017 at 22:11

OK, it might be a flaw in the SDMMC hardware.

I tried adding an instruction to clear the static flags after the CMD8, but that did nothing. So I was searching the web for clues and I came across some code somebody had written for an STM32 SDMMC that was similar to the example code, but a little different.

In the example code they send a CMD8. If it succeeds they mark the card as v2.0 and continue. Then they try the CMD55. If that fails they give up and assume it's an MMC card. If it succeeds they then do another CMD55 followed by the ACMD41. I thought it was odd that they did a second CMD55 instead of just doing the ACMD41 right after. In the SD specs they say to do the CMD55 and if it succeeds then do an ACMD41.

In the code I found on the web, he also did the CMD55 twice, but the big difference is that he ignored the response of the first one and in the comments he said it was to reset the illegal command of the previous step. !!!

So I tried adding another copy of the CMD55 command between the CMD8 and the first CMD55 in the example code, and ignored the result, to see if that would reset the illegal command result I was getting. It did! With that added CMD55 in there then the code works and the small cards test fine and my program can read the directory and display the filenames on the 1GB and 1/2GB cards.

Looking at the code, there is virtually nothing to it. It sends the command by setting values in the SDMMC CMD register and it gets the response by reading the SDMMC RESP1 register. So there's very little code in there to be wrong. I'll dig deeper to make sure there isn't some flaw in the way it interprets the status bits, but at the moment it seems like maybe there is some flaw in the hardware that causes the illegal command bit to stick around from the previous command. And I'm going to have to rewrite the logic of this section of the SD_PowerON() function, because now there are three copies of the CMD55, and that's just dumb.

Nemui Trinomius · ‎2017-03-16

Posted on March 17, 2017 at 01:18

For SDv1 Cards and MultiMediaCards,should be send CMD0 to return idle state once after CMD8 banned.

But ST Codes

abruptly

try to send CMD55 + ACMD41.

Dave Jones · ‎2017-03-19

Posted on March 19, 2017 at 20:26

That sounds logical. However the flow chart in both the Simplified SD Host Controller Spec v2.0 and in the Physical Layer spec 5.0, for the Card Initialization and Identification flow chart, both show that if the CMD8 gets no response they then go directly to the CMD55/41.

I don't have a logic analyzer handy, but I would like to look at the actual response coming back from the card for the CMD55 right after the CMD8 to see if the card is actually sending an Illegal Command bit with the response to the CMD55 or if that is something left over in the SDMMC interface from the failed CMD8. That would clarify if it's a bug in the STM hardware or in the SD Card spec flow chart.

AVI-crak · ‎2017-03-19

Posted on March 20, 2017 at 02:23

To the place thousands of words.

https://members.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf