VHDL - SDCARD lock ups

[Curt Vendel]

Anyone work in VHDL?

 

I'm running into random intermittent lockups on an SDCARD interface. I'm going the SPI route and things were stable and well for a while, but now I can't nail down why the interface will lock up in different load locations when testing out the loading of rom images into a new design for a 2600 I've been messing with.

 

Before I start over and change to I2C, I wanted to see if anyone else has encountered these problems and if they are using SPI or I2C.

 

 

 

Curt

[GroovyBee]

PM sent

[+poobah]

Anyone work in VHDL?

 

I'm running into random intermittent lockups on an SDCARD interface. I'm going the SPI route and things were stable and well for a while, but now I can't nail down why the interface will lock up in different load locations when testing out the loading of rom images into a new design for a 2600 I've been messing with.

 

Before I start over and change to I2C, I wanted to see if anyone else has encountered these problems and if they are using SPI or I2C.

 

 

 

Curt

 

If you have something you'd like another set of eyes to look at, send it my way.

[candle]

i've did SPI code for speeddrive in vhdl

most problems i had were that at max speed (50mhz oscillator) 8 clock pulses sometimes became 7, but that was cured in a only possible way - limiting clock to 25mhz (i was using 2 asynchronous clocks to speed up things)

if You want, You could send it my way

[matthew180]

Did you find a solution? I started working with and learning VHDL about 4 or 5 months ago and I'd be interested in knowing the outcome of your problem and how you fixed it. I have yet to find a really good FPGA forum that has an enthusiastic user base, and talking VHDL with other A.A. members would be pretty cool IMO.

 

Matthew

[ijor]

Sorry for being a bit late to this ...

 

I'm afraid the answer is, in my own experience, that there is no foolproof solution for SPI. The problem is that some card manufacturers don't do much testing, if at all, under SPI mode. Remember that commercial card readers use native SD mode, not SPI. SPI support is somewhat optional, and it was never fully formally specified (not as much detailed as native SD mode).

 

The best solution is then, to implement native SD mode. Even 1-bit SD mode is more reliable than SPI mode.

 

I'm not sure what you mean about trying I2C. SD cards don't support I2C.

[+batari]

Sorry for being a bit late to this ...

 

I'm afraid the answer is, in my own experience, that there is no foolproof solution for SPI. The problem is that some card manufacturers don't do much testing, if at all, under SPI mode. Remember that commercial card readers use native SD mode, not SPI. SPI support is somewhat optional, and it was never fully formally specified (not as much detailed as native SD mode).

 

The best solution is then, to implement native SD mode. Even 1-bit SD mode is more reliable than SPI mode.

 

I'm not sure what you mean about trying I2C. SD cards don't support I2C.

You have to pay royalties (something like $3000/year) to the SD card association if you wish to use the SD modes. The specs are not publicly available and cost something like $500 just for that. That's really not feasible for the hobby projects we do. SPI, however, is an open standard.

[ijor]

You have to pay royalties (something like $3000/year) to the SD card association if you wish to use the SD modes. The specs are not publicly available and cost something like $500 just for that. That's really not feasible for the hobby projects we do. SPI, however, is an open standard.

 

Well, yeah. You are, at least, partially right. But unfortunately it is not black or white.

IANAL

 

In theory (according to the SD card assoc.), you hay to pay royalties either way, regardless if you use SPI or SD mode. I have read some claims that as long as you use SPI mode only, then you are "safer" against being sued, because the SD mode is covered by patents and SPI is not. IANAL (again), but I'm not sure it makes much sense. SPI/SD mode is just one layer of the whole SD specification. So even if the SPI layer is free, the other layers are/might be not. If you have a link to an authoritative paper showing that accessing SD cards with SPI mode is free, then I would like to see it.

 

Specifications are absolutely not a problem. Is is true that the full specifications are not publicly available, but this (once again) is regardless of using SPI or SD mode. Either way, there are both partial simplified specs that are officially disclosed, and also reverse engineered by third parties, plus the open and free MMC specifications. Furthermore, there are free open source implementations.

 

IANAL once more again, but if you want to be 100% safe and purist, then I'd avoid SD cards altogether, use MMC (or compatible) or CF cards only. OTOH, for most hoppy projects, the legal risk of using SD cards, even in SD mode, is as small as the risk of an Atari emulator being sued by Atari (or MOS, or Motorola/Freescale).

 

Regardles of this legal debate, I insist with my original technical point. Using SPI mode is, unfortunately, not 100% reliable.

[+batari]

Sure, the SD assoc. is not going to say that using SPI/MMC modes (which we did exclusively) is OK. However, it's hard to argue that they would have any legal leg to stand on.

 

However, using SD modes is a clear violation of their patents.

 

Anyway, we got SPI working nearly 100%. We just had to ignore an initialize acknwledge or something as some cards refused to send one.

[ijor]

Sure, the SD assoc. is not going to say that using SPI/MMC modes (which we did exclusively) is OK. However, it's hard to argue that they would have any legal leg to stand on.

 

Hmm, you are using the SPI and MMC terms as if they would be equivalent in this context. And they are not. As you surely know already, you can do MMC with both SPI and native bus protocol, and you can do SD mode with both SPI and native bus protocol. So one thing is SD vs. MMC, other is SPI vs. native non-SPI mode. I'm not trying to be picky, just not sure what you mean exactly.

 

If you are saying that it is legally safe to use a MMC compliant host controller, without using any specific SD feature, that could use SD cards just because they are backwards compatible, then I agree. There is still a minor issue. The slot can't follow the MMC specifications, it must be a SD card slot (SD cards are mechanically backwards compatible with MMC, but not the other way around). No idea if this might have legal implications.

 

However, if you are saying that it is legally safe to use specific SD features, as long as you use SPI and not native bus mode, then I'm not so sure. I'm not saying you are wrong, I just couldn't find any evidence or authoritative claim. SD cards are protected by many patents, not just the native 4-bit mode. It is true that most patents seem to be relevant to manufacturing a card, and not a host. But I wouldn't dare to reach a conclusion without a lawer studying the patents.

 

However, using SD modes is a clear violation of their patents.

 

Not exactly. The SDA hold patents for the 4-bit mode. The native 1-bit mode (which is not SPI) can't be, because it is part of the free MMC specifications. So once again, I don't see any legal difference between using SPI or native mode (at least as long as you use 1-bit only).

 

Again, if you have a link to an authoritative article claiming that SD/SPI mode is 100% legal, I would love to be proved wrong.

Edited November 12, 2010 by ijor

[+batari]

Sure, the SD assoc. is not going to say that using SPI/MMC modes (which we did exclusively) is OK. However, it's hard to argue that they would have any legal leg to stand on.

 

Hmm, you are using the SPI and MMC terms as if they would be equivalent in this context. And they are not. As you surely know already, you can do MMC with both SPI and native bus protocol, and you can do SD mode with both SPI and native bus protocol. So one thing is SD vs. MMC, other is SPI vs. native non-SPI mode. I'm not trying to be picky, just not sure what you mean exactly.

 

If you are saying that it is legally safe to use a MMC compliant host controller, without using any specific SD feature, that could use SD cards just because they are backwards compatible, then I agree. There is still a minor issue. The slot can't follow the MMC specifications, it must be a SD card slot (SD cards are mechanically backwards compatible with MMC, but not the other way around). No idea if this might have legal implications.

 

However, if you are saying that it is legally safe to use specific SD features, as long as you use SPI and not native bus mode, then I'm not so sure. I'm not saying you are wrong, I just couldn't find any evidence or authoritative claim. SD cards are protected by many patents, not just the native 4-bit mode. It is true that most patents seem to be relevant to manufacturing a card, and not a host. But I wouldn't dare to reach a conclusion without a lawer studying the patents.

We are using SPI in such a way that it supports only features in the MMC spec, but these happen to work on SD.

However, using SD modes is a clear violation of their patents.

 

Not exatly. The SDA hold patents for the 4-bit mode. The native 1-bit mode (which is not SPI) can't be, because it is part of the free MMC specifications. So once again, I don't see any legal difference between using SPI or native mode (at least as long as you use 1-bit only).

You are implying that 1-bit mode is an MMC mode, not a specific SD mode, so sure, specific MMC modes should be fine, but it shouldn't matter whether you do that through MMC-native or SPI protocols.

Again, if you have a link to an authoritative article claiming that SD/SPI mode is 100% legal, I would love to be proved wrong.

The SDA has never answered that question (you can ask, but you'll get the runaround.) They would rather have someone pay them than specifically endorse free use, even if they have no legal authority against anyone accessing SD cards using open protocols that are fully MMC compatible. My main issue is that you seem to be implying that since the legal status of SPI has never been acknowledged by the SDA, you might as well use the modes that are certainly illegal. I don't agree with that, even if the SD-native modes are more reliable.

 

Anyway, while not a specific proof of the legality, I'll refer you to this application note from our chip manufacturer, which pertains to the specific chip we are using, and not only contains specific details about how to use SPI on MMC/SD cards with the chips, it even contains an open source driver.

 

http://ics.nxp.com/support/documents/microcontrollers/pdf/an10406.pdf

Edited November 12, 2010 by batari

[ijor]

We are using SPI in such a way that it supports only features in the MMC spec, but these happen to work on SD.

 

I agree that in this case, you are legally safe (well, except the potential issue of the mechanical adapter).

 

The main problem I found when using MMC features only, is that you can't use SDHC cards (not a problem at all in many applications).

 

The SDA has never answered that question (you can ask, but you'll get the runaround.) They would rather have someone pay them than

 

Yeah, I am aware about the SDA position. But when I said "authoritative", I meant it in a more generic sense. E.g., if specialized lawyers studied the issue and reached the conclusion that SPI mode is ok (despite what the SDA might claim).

 

My main issue is that you seem to be implying that since the legal status of SPI has never been acknowledged by the SDA, you might as well use the modes that are certainly illegal. I don't agree with that, even if the SD-native modes are more reliable.

 

I didn't said exactly that. I said that the legal difference seems to be between MMC vs. SD, and between 1-bit vs. 4-bit (or higher). There doesn't seem to be any legal difference whatsoever between using SPI mode or using native 1-bit mode.

 

So I am saying. If you can, use 1-bit mode instead of SPI. It is more reliable, and it shouldn't affect the legal status in any way whatsoever. As long as use MMC features only, then it should be fully legal (disregarding if SPI or native 1-bit mode). But as soon as you use any SD specific features (such as, say, SDHC) then there is (or might be) a legal problem, even when using SPI mode.

 

Anyway, while not a specific proof of the legality, I'll refer you to this application note from our chip manufacturer, which pertains to the specific chip we are using,...

 

Many thanks. But the note uses strictly MMC features only, no specific SD features. It is an MMC driver.

 

Btw, if you are using a micro like this, then you are restricted to SPI anyway. You need specific hardware support for native mode (even for 1-bit).

 

Btw2, just curious, why you decided to use specifically an NXP micro? Nowadays, seems that almost everybody uses Atmel or PIC for hobby projects.

[+batari]

Btw2, just curious, why you decided to use specifically an NXP micro? Nowadays, seems that almost everybody uses Atmel or PIC for hobby projects.

The NXP processor had excellent performance for the price. For the same price as the 32-bit NXP, the others had 8-bit processors with half the I/O lines and a fourth the clock speed. Also, I am partial to the ARM instruction set.