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 support@ccsinfo.com

SD Card oddities

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Guest








SD Card oddities
PostPosted: Mon Nov 10, 2008 5:07 pm     Reply with quote

I'm using PCD 4.079 and a dsPIC30F4011. I'm using sparkfun's MMC/SD breakout board, and voltage dividers on the SDO, SCK, CS, and VDD lines. Using ex_mmcsd.c, I've been able to successfully write and read data. But it seems like the first byte either isn't written or isn't read. If I do this:
Code:

address = 0x00001234;
for(x=0;x<5;x++)
{
  mmcsd_write_byte(address,x); 
  mmcsd_read_byte(address++,&val);
  printf("value = %u, ",val);
}


The output is "value = 104, 1, 2, 3, 4,"

but if I put a dummy write in front of the for loop, everything works fine.

Then, If I separate the writing and reading into separate files, and still write 1,2,3,4,5 to consecutive addresses, I get back 1,4,6,8,10.

Does this make sense to anyone?
Guest








PostPosted: Mon Nov 10, 2008 8:03 pm     Reply with quote

Edit: In the two program scenario, the sequence stored is 0,1,2,3,4, not 1,2,3,4,5.
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

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

Re: SD Card oddities
PostPosted: Mon Nov 10, 2008 8:10 pm     Reply with quote

Anonymous wrote:
I'm using PCD 4.079 and a dsPIC30F4011. I'm using sparkfun's MMC/SD breakout board, and voltage dividers on the SDO, SCK, CS, and VDD lines.


I assume you mean SDO out from the PIC - SDI in to the card.

What do you mean by voltage divider on VDD?

If you mean by this that you are attempting to generate 3.3volts from 5 volts for the card using a voltage divider then this will not work. The cards consume a very low average current but consume a high current during a write operation - up to 200mA worst case for a standard SD card.

If you do not want to use a LDO regulator to derive the 3.3volts then you could use 2 x 1N4148 diodes in series between the +5v rail and the +3.3 volt rail of the card. If you do this then add a 100K resistor from the cards 3.3volt rail to ground. In addition you should add a 10uF ESR (such as tantalum) capacitor and a 0.1uF monolithic capacitor between the power and ground terminals of the socket.

Do you also have a pullup resistor on SDO out of the card (SPI IN to the PIC)?
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Guest








PostPosted: Mon Nov 10, 2008 8:51 pm     Reply with quote

I know the signals are going to the right pins. It wouldn't work even intermittently if they weren't.

Yes, I am creating ~3.3V from 5V with a 3k and a 1.6k. I do know that my wall wart powering my devboard, and therefore the sd card, is limited to 200mA. I guess I assumed that it couldn't work intermittently. I have no problem using a regulator, I was really just doing a proof of principle, and keeping it simple.

I will try a 3.3V regulator, a beefier power supply and a 10k pullup resistor.
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

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

PostPosted: Mon Nov 10, 2008 9:19 pm     Reply with quote

In this case I am surprised you got it to work as well as you did.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Guest








PostPosted: Tue Nov 11, 2008 2:35 pm     Reply with quote

I've put an adjustable regulator, set to 3.3V and a 15k pullup to 5V on the Data out pin from the SD card. I still get the same error, a bad first byte read back.

I've also noticed that I have to run the code twice to get output. The first time it runs, it hangs. But on a reset, it works. Another reset makes it hang again, and yet another makes it work again. So I kept advancing an output_high(PIN_B1) statement (turns on an LED) to see how far the code makes it, and where it hangs.

What I found was that on the times is doesn't work, the if (g_MMCSDBufferChanged) statement in mmcsd_flush_buffer() evaluates to true, while on the times it does work, the if statement fails.

So, when the buffer has changed, the buffer is flushed, and mmscd_write_block() is called. Inside this function, towards the end, there is a while() statement that writes 0xFF to the SPI bus and won't exit until a 0 is returned. My problem stems from the 0 never being returned, and the while loop becomes infinite.

Once I commented out the while() statement, it works every time. This does not correct the need for the extra dummy write at the beginning though.

So I have two workarounds to make it work, not waiting for the SPI line to return to low, and writing a dummy byte. But I would still like to get to work without the workarounds.

Any ideas?
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

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

PostPosted: Tue Nov 11, 2008 3:50 pm     Reply with quote

Anonymous wrote:
I've put an adjustable regulator, set to 3.3V and a 15k pullup to 5V on the Data out pin from the SD card.


Is the regulator an LDO device? You needs one that will work with a minimal voltage drop from input to output (<1.25 volts).

The pullup should be to 3.3 volts this is because the SD card is only open drain during initialization and totem pole output otherwise.
Quote:

I've also noticed that I have to run the code twice to get output. The first time it runs, it hangs. But on a reset, it works. Another reset makes it hang again, and yet another makes it work again.


Are you sure about the final step? Without the final step it indicates a problem in the initialization stage. The final step indicates otherwise.

I can not comment on the the driver calls you are making because I use my own drivers however, ignoring the final step it looks like an SPI bus initialization problem - I suspect when the bus speed is being changed.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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