Basic SDIO on F4 discovery board

[chichkinei]

Posted on September 15, 2012 at 09:58

Can anyone please provide me with a link to some basic, low level, 4-bit SDIO interface code compatible with the STM32F4VGT? I'm not looking for it to support a file system(yet), I just want to be able to read bytes from a uSD card. I've seen a few examples out there but I don't understand enough about C to understand all the high level stuff, let alone figuring out how to get TrueSTUDIO to compile it.

#metoo

[Tesla DeLorean]

Posted on September 15, 2012 at 13:37

STM32F4xx_DSP_StdPeriph_Lib_V1.0.0\Project\STM32F4xx_StdPeriph_Examples\SDIO\uSDCard

About as basic as it gets.

[chichkinei]

Posted on September 16, 2012 at 02:23

Unfortunately this is exactly the high level, complex code I was talking about. If this is really as simple as it gets then I have some figuring out to do. I was thinks more along the lines of a few low level function which just read and write the SDIO registers. I can't find any information on these registers in the STM32F407 datasheet so I don't even know where to start.

Also, whats wrong with this website? I had 2 different errors trying to post this and had to retype it!

[Tesla DeLorean]

Posted on September 16, 2012 at 05:11

Unfortunately you can't just peek/poke into some registers, the cards are a bit like hard drives and act as block storage devices, handling the flash array and wear leveling. You should perhaps start with the MMC/SD card standards documents and gain some perspective.

Consequently you need quite a large interface layer on top of the physical hardware connection to the device. The aforementioned example gets you to the block/sector access level, which is about where you need to start coding without getting lost in the mechanics of the cards themselves. Yes the forum software is by Microsoft, and is awfully bad.

[chichkinei]

Posted on September 24, 2012 at 04:12

Ok, so I finally got the example to compile and I uploaded to my board with some modifications (I changed the SD detect pin to D11 in stm324xg_eval.h and I changed the on-board led pinout to match my board) but it's still not working properly.

Most of the time it gets stuck in a flag check loop somewhere in SD_Init before led 4 can turn on. Sometimes led 4 turns on indicating that something went wrong (after some debugging it seems that the SD card is recognized as an MMC card and then receives an illegal command), and very rarely it erases the first 100 512 byte blocks and gets stuck somewhere after that. Never have I gotten the leds 1, 2, and 3 to turn on (indicationg that is got to the end of the example successfully). After looking through the example it looks like SD_EraseTest should execute which, as the comment states, ''Erase NumberOfBlocks Blocks of WRITE_BL_LEN(512 Bytes)''. Number of blocks is defined as 100 so in theory it should just delete the first 51200 bytes of the card, which is where the MBR resides hence Windows telling me that the card isn't formatted after a successful run. Looking at the card with a hex editor confirms that the data was erased. So really I just need to figure out why it's being so unreliable right now. I don't have pullups on any of the pins which might be the problem. I've tried reducing the init and transfer clock speed but that didn't help.

[Tesla DeLorean]

Posted on September 24, 2012 at 15:44

Will definitely break without pull-up resistors. 33K or 47K will suffice. You'll need to pick your own card detect pin.

I've posted the MSC and FatFs examples to the STM32F4-Discovery with a MicroSD socket. These have been posted against the forum several times.

https://docs.google.com/open?id=0B7OY5pub_GfIcU1XTDFDRlptZDg

https://docs.google.com/open?id=0B7OY5pub_GfIaUozb1VsY3Flb1E

[chichkinei]

Posted on September 25, 2012 at 06:40

Ok, I added the pullups and it worked a lot more reliably (erased the first 100 blocks every time) but it was crashing somewhere just after the block erase. I was debugging and found that it made it through SD_ReadMultiBlocks (right after the block erase), but at that point TrueSTUDIO decided to crash and give me a blue screen. Now for some reason I'm getting stuck in the flag check loop in SD_Init again, specifically this:

while
(!(SDIO->STA & (SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))
{
if
(SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET)
{
*(tempscr + index) = SDIO_ReadData();
index++;
}
}

where RXDAVL is always reset. I think this is happening because I'm not communicating at all with the card anymore, so I'm not receiving timeout flags and it's stuck. I'm sure that if I just figure out this one bug it will work again. I have no clue why it just stopped working after TrueSTUDIO crashed though.

[chichkinei]

Posted on September 26, 2012 at 04:26

Ok it turns out that my HSE was defined as 25MHz after the crash whereas is was 8Mhz before, so I was getting the wrong SD clock. Now I'm back to the other problem. It gets through SD_ReadMultiBlocks but gets stuck or does something wrong after that. Debugging tells me that SD_WaitReadOperation always returns SD_DATA_CRC_FAIL, and most of the time it gets stuck after that in

/* Wait until end of DMA transfer */
while
(SD_GetStatus() != SD_TRANSFER_OK);
}

I'm starting to see light at the end of the tunnel, but I'm still not quite there yet.

[chichkinei]

Posted on September 27, 2012 at 03:13

Alright after some more messing about, I've made a little program which reads data from the card and displays it on my LCD. Now I understand why I was getting so many errors and why none of the examples 'PASSED'. A whole lot of my data is being messed up as it gets from the SD card to the MCU as can be clearly seen in the picture I attached. This is with the SD clock at 16MHz. If I go up to 24MHz, it's far worse, and if I go less than 16MHz it's the same. I also tried removing the pullups just to see the difference and it was the same as with pullups. I'm doing the necessary

Status = SD_WaitReadOperation();
while
(SD_GetStatus() != SD_TRANSFER_OK);

after reading each block so I don't know why the data is being corrupted. It's always in the same exact place as well. SD_ReadMultiBlocks also fills the buffer with 0x00 for everything except the first block for some reason, although that's not currently the main concern. ________________ Attachments : P1090672.JPG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I03c&d=%2Fa%2F0X0000000bT7%2FNefPAiT_CUR0biU6qLEPqYzcnxGNEcI3.ANQ1vHK1fc&asPdf=false

[chichkinei]

Posted on October 04, 2012 at 22:24

After some more testing I've found that I get corruption on transitions between the states of the data lines. For example, if I read 0x0F (which, in 4 bit mode, is 0000 transitioning to 1111) then I get corruption. If I read 0x0E, however, there's no problem. This lead me to believe that my pullups weren't strong enough (even though they were 10k) so I went all the way down to 470 ohms. While this did make 0x0F read correctly I still can't read 0x00 followed by 0xFF and there's no way that my pullups should be that strong. Without an oscilloscope I have no way of knowing what the rise/fall time of the data lines is etc. I don't know how useful any of this information is but if anyone has a clue as to what's going on please reply.