CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Unable to put some SD cards in idle state
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
JerryR



Joined: 07 Feb 2008
Posts: 167

View user's profile Send private message

Unable to put some SD cards in idle state
PostPosted: Fri Jul 28, 2017 9:14 am     Reply with quote

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: 19542

View user's profile Send private message

PostPosted: Fri Jul 28, 2017 1:22 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Jul 28, 2017 1:59 pm     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Fri Jul 28, 2017 7:54 pm     Reply with quote

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: 9244
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jul 29, 2017 4:59 am     Reply with quote

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: 19542

View user's profile Send private message

PostPosted: Sat Jul 29, 2017 8:42 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 6:06 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 6:11 am     Reply with quote

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: 19542

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 6:28 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 6:40 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 7:10 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 7:43 am     Reply with quote

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: 19542

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 7:48 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 8:08 am     Reply with quote

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: 19542

View user's profile Send private message

PostPosted: Mon Jul 31, 2017 10:06 am     Reply with quote

OK. So the code works and the hardware works. You now need to work out what is stopping it when using your original code.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group