View previous topic :: View next topic |
Author |
Message |
JerryR
Joined: 07 Feb 2008 Posts: 167
|
Unable to put some SD cards in idle state |
Posted: Fri Jul 28, 2017 9:14 am |
|
|
I've been working on this issue for a solid month, without resolution. Using Brush Electronics SD FAT system with various SD cards. Lower capacity SD cards seem to mount correctly, however I can't seem to get higher capacity SDHC cards to enter idle state.
Please refer to the logic traces at:
https://drive.google.com/drive/folders/0B2OU7T0b3oetUUxaNDNFeEFaZ0U?usp=sharing
Send 80 clock pulses
10 ms later send 40 0 0 0 0 95 (CMD0)
Good card responds with 0x01
Bad cards do not respond with 0x01
There are no other SPI devices enabled on the SPI bus when I'm communicating with the SD card. I have tried multiple card types and manufacturers with the same results.
Does anyone see anything that I'm missing here. I would really appreciate the group's help. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Fri Jul 28, 2017 1:22 pm |
|
|
Unfortunately some of the newer cards (a lot), are actually fussier about the init sequence than older cards.
Problem is the Brush driver on faster PIC's, clocks the line too fast for the specification. This is because the required rate is below the minimum that these chips can clock the hardware SPI....
Most older cards don't actually care about the rate.
I got round it by declaring two streams on the same pins. One using the hardware SPI, set to the maximum rate, with 'noinit' specified (SD_SPIHW), and the other software, and the slow initialisation rate (SD_SPISW). I then got rid of the lines in the driver setting the divider, and instead use:
Code: |
spi_init(SD_SPIHW,FALSE); //turn off hardware
//then use
spi_xfer(SD_SPISW,value); //to send the initialisation values
//at the low rate
//Then to switch to the high rate
spi_init(SD_SPIHW,TRUE); //to enable the hardware
//and use
spi_xfer(SD_SPIHW,value); //for the SPI commands after this
|
I've also seen problems with some new cards not wanting to come out of idle unless the command is repeated....
You may also need to pause before initialising the card. Some larger cards take quite a long time to be ready after boot. On a fast PIC, this can be a problem.
Also look here:
<https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/294813> |
|
|
JerryR
Joined: 07 Feb 2008 Posts: 167
|
|
Posted: Fri Jul 28, 2017 1:59 pm |
|
|
Ttelmah:
Thanks a lot for your input. That could explain why some cards work and other don't. Currently my clock speed for SPI transfers is around 300Khz. I'll work around with the timing to see if I can encourage the "faster" cards to mount.
I appreciate your (and the group's) input on this. This issue has been a real bear!
Best regards |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Fri Jul 28, 2017 7:54 pm |
|
|
JerryR wrote: | Ttelmah:
Thanks a lot for your input. That could explain why some cards work and other don't. Currently my clock speed for SPI transfers is around 300Khz. I'll work around with the timing to see if I can encourage the "faster" cards to mount.
I appreciate your (and the group's) input on this. This issue has been a real bear!
Best regards |
The most common reason for this problem is a missing pull-up resistor on DO of the card. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9246 Location: Greensville,Ontario
|
|
Posted: Sat Jul 29, 2017 4:59 am |
|
|
I was thinking like Andrew. Either a missing pullup or pull down resistor, as there NEEDS to be the correct combination. I can't see the card mfrs putting them in (cost 4c), then the interface mfr will 'assume' the card guys do it, sigh.
Hmm, BOTH could have added them, which could cause problems too !!
Best to ring out and confirm EACH line is properly terminated.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Sat Jul 29, 2017 8:42 am |
|
|
Also though the delay.
I've been caught by this on a couple of recent cards, which don't actually seem to start their wake up till the supply gets well above the point where the PIC starts to wake. I've seen some recent cards take up to 3 seconds to wake!....
The other thing is power. The spikes that can actually be drawn by the cards are large. Insufficient smoothing close to the card, can easily give odd behaviour. |
|
|
JerryR
Joined: 07 Feb 2008 Posts: 167
|
|
Posted: Mon Jul 31, 2017 6:06 am |
|
|
All:
Thanks for your responses. Please be aware, I have 10K pull-ups as needed. Please consider the logic traces as shown.
I have little doubt that this is a software / compatibility issue. Currently yhe code is stock code sent by Andrew at Brush.
Anyone have any suggestion as to how slow the SPI clocking needs to be to accommodate putting the "faster" cards into SPI mode?
Thanks! |
|
|
JerryR
Joined: 07 Feb 2008 Posts: 167
|
|
Posted: Mon Jul 31, 2017 6:11 am |
|
|
Ttelmah: Sorry didn't address your suggestions. Power to SD cards have smooth 3.3 volts with 22uF and 0.1uF capacitors on the SD card's supply pins. Power is on constantly (at least 3 seconds) before attempting to mount cards.
Currently, I can only get 2GB SD cards to mount properly. I now have a collection of 30 or so cards which are SD or SDHC 4GB and up that don't mount.
Thanks again |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Mon Jul 31, 2017 6:28 am |
|
|
What actual PIC are you using?.
On the fast chips (PIC24 etc.), the hardware can support the lower rates.
Use:
Code: |
#USE SPI (SPI1, MODE=0, FORCE_HW, BAUD=100000, STREAM=SDCARD)
|
and switch speeds with:
Code: |
DeselectSD;
spi_init(SDCARD,FALSE);
spi_init(SDCARD,8000000); //8MHz
spi_init(SDCARD,TRUE);
SelectSD;
|
Where I had real trouble was on a couple of the fastest PIC18's, where I have already described how to do it (with the double streams).
I also have it running really fast on two chips using DMA, but this is commercial. Can drop some hints on this, but it is a major re-write. However performance at 8MHz has been adequate for most applications. |
|
|
JerryR
Joined: 07 Feb 2008 Posts: 167
|
|
Posted: Mon Jul 31, 2017 6:40 am |
|
|
Ttelmah:
Again, many thanks for your thoughts. Unfortunately, I'm using a PI18F87J60 using external 25MHz crystal, I am using the SPI bus to communicate with an LED driver and EEPROM which both use the hardware SPI lines. Both of these devices are completely disables during SD operations. Additionally, i am only calling SD card routines while working on this SD card issue. Code is now 23,000 lines
Really wished i had started with my own code rather than using the "canned" Brush code. Andrew insists that his stock code is compatible with all SD card formats.
And again, thanks! |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Mon Jul 31, 2017 7:10 am |
|
|
JerryR wrote: | Really wished i had started with my own code rather than using the "canned" Brush code. Andrew insists that his stock code is compatible with all SD card formats. |
I'm a long time customer of Andrew's as well, and his code is compatible with all SD card formats. I've used cards ranging from 500MB (large SD card format) to 32GB (uSD format) with no issues. I've used his driver with PIC18's and dsPIC33's.
There's something else you're missing. There has to be. |
|
|
JerryR
Joined: 07 Feb 2008 Posts: 167
|
|
Posted: Mon Jul 31, 2017 7:43 am |
|
|
newguy:
It sure is a mystery to me why some cards work fine and consistently and others do not. Consider my logic diagrams and tell me what you see as being wrong. I'd appreciate any and all input.
Regards, |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Mon Jul 31, 2017 7:48 am |
|
|
I think the first thing to do is simplify.
Forget about your 23000 lines of code, and run one of the basic SD demos that are supplied with the Brush drivers.
At 25Mhz, the SPI will go down to 390625Hz without problems. Where I had problems was with chips up at 64Mhz, where the low speed was 1Mhz, and some cards did not like initialisation at this rate.
What is supplying the 3.3v?. What current can this deliver?.
Remember an SD can draw 200mA, and generates spikes of much higher currents at nSec timings. They are fussy beasts regarding power.
Do you have all the pullups as shown on Andrew's circuit?. Technically the two on the unused Dat1 & Dat2 lines are _required_ by the spec.
Both grounds connected?. |
|
|
JerryR
Joined: 07 Feb 2008 Posts: 167
|
|
Posted: Mon Jul 31, 2017 8:08 am |
|
|
Ttelmah:
Yes, re-worked Brush code to work with my hardware and are working with the basic Brush code. All pull-ups are IDENTICAL to brush hardware requirements. Power supply is practically flat during mount attempts.
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Mon Jul 31, 2017 10:06 am |
|
|
OK. So the code works and the hardware works. You now need to work out what is stopping it when using your original code. |
|
|
|