SPI returns partially bad data when reading SD memory block

Post
meloware
New Member
2007/06/09 15:05:20
I have a ‘Daisy’ mp3 player (http://www.teuthis.com/html/daisy_mp3.html) , and it works fine, as pre-programmed. I am trying to adapt the source code(written for CCS PCH C compiler), so that it compiles and works properly with C18 . I’m using the hardware SPI feature on the 18F45j10, to read the SD memory chip.
 
My SD memory is Fat32 formatted, and I am able to inspect the actual data with a USB media reader, and a physical sector read utility.
 
Any ‘read block’ commands I issue with my code, always return defective data, when the last (LSB) three address bits are either ‘100’, or ‘101'.
 
For example, my block of data at sector 141 actually is:
01 14 00 00 02 14 00 00 03 14 00 00 04 14 00 00
 
A series of SPI  ReadSPI()  calls will return:
01 14 00 0F 04 14 00 00 03 14 00 00 0F 04 00 00
 
No matter what 512 byte SD memory block I open,  the 4 LSB bits of byte 0x?4 and 0x?C will be set to ‘F’, and bytes 0x?5 and 0x?D will be 0x04!
 
Now, I have about 400 lines of ‘bare bones’ code I can post, and I really would appreciate some help. I am a newbie to SD memory and PICs, but just can’t imagine how it is possible to be able actually access the memory, and get only PARTIALLY bad data!
 
I am using:
MPELAB 7.6
C18 C Compiler v3.11
Hardware SPI library (spi.h, from the C18 install)
I get the same result with SPI modes:
   OpenSPI(SPI_FOSC_64, MODE_00, SMPEND); //or SMPMID
And   OpenSPI(SPI_FOSC_64, MODE_11, SMPEND);
 
meloware
New Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/09 17:36:58
I have posted the project, as is, on my website. It will run in /mp3/xxx/ with the C18 compiler in /mcc18.

I am sorry for the extra code - the 'bare bones' version wound up being too bare bones to run!

zipped project at http://www.meloware.com/code/SPI-SD_memory_problem.zip
Neiwiertz
Super Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 03:48:19
Hi meloware

Try this to read a block http://forum.microchip.com/fb.aspx?m=259776


meloware
New Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 09:22:51
Well, thank you. I realize I may be in the wrong forum for this. It looks like my problem is with my lack of understanding the SPI for my chip (18F45j10), than the SD commands and code. The thread you suggested is for a very different MCU, and I don't see any straight forward way to translate it.

I now realize that my problem is with any number of reads done with the SPI as configured.  I have the same kind of error  in reading the SD card's  CSD  and CID.

I guess this is my most likely route to a solution. I would still appreciate some help in setting up my particular MCU, but it looks like if I keep struggling with AN1003 and the other related posts, I may eventually figure it out.
dhenry
Super Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 10:11:14
I get the same result with SPI modes:
   OpenSPI(SPI_FOSC_64, MODE_00, SMPEND); //or SMPMID

For what it's worth, a quick glance at the original (CCS) source has the SPI configuration equivalent to:
OpenSPI(SPI_FOSC_64, MODE_00, SMPMID);
Then it appears to change speeds using the SPI mode select clock bits during runtime.
asmallri
Super Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 10:46:34
ORIGINAL: meloware

Well, thank you. I realize I may be in the wrong forum for this. It looks like my problem is with my lack of understanding the SPI for my chip (18F45j10), than the SD commands and code. The thread you suggested is for a very different MCU, and I don't see any straight forward way to translate it.

I now realize that my problem is with any number of reads done with the SPI as configured.  I have the same kind of error  in reading the SD card's  CSD  and CID.

I guess this is my most likely route to a solution. I would still appreciate some help in setting up my particular MCU, but it looks like if I keep struggling with AN1003 and the other related posts, I may eventually figure it out.


The SPI code to support SD cards with the PIC18F45J10 is identical for the PIC18F2620/4620/8722 (non J) families. Are you sharing the SPI bus with any other peripherals? - If so have you disabled the chip selects?
meloware
New Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 12:52:04
I am using the SPI1 for the SD memory access and it’s transfer to the vs1011 mp3 player chip.
 
#define MMCSS          LATCbits.LATC1     //this is chip select for the MMC/SD
#define XCLK_l                       LATCbits.LATC3  // the SD clock and the vs1011 clock
#define XDI_l               LATCbits.LATC4  // data in from the SD and also connect to the vs1011 input
RC5     SPI data out – only to the SC card
 
Although the chip select line to the vs1011 mp3 player is kept high (chip disabled), I gave it a hard reset anyway after Asmallri’s comment. I still get the error.
 
So, the MCU’s data out is only connect to the SC card’s data in, and a resistor pack pull-up. The MCU’s data in is connected to a pullup, the SD data out, and the vs1011’s data in, and the vs1011 is held de-selected anyway. The clock goes to both the SD card and the vs1011 clock input.
 
The SD’s ‘media detect’ and ‘write protect’ pins are unused and pulled high.
 
The post that suggested the ‘dragstar car’ code is using the p24FJ128GA010, and refers to a bunch of stuff like, “SPI1CONbits.DISSCK”, and “SPI1CON1.MODE16”. I can’t even find the header file which defines this stuff, so I haven’t figured out how to make use of this example. Remember, I am using C18.
 
I’d like to try the example, ‘dragstar car’, if anybody could please point me to how to the definitions for the chip I am using.
 
Right now, I am trying to strip out the USB stuff from AN1003. I am stuck a bit on how to define the “extern volatile far byte msd_buffer[512]” buffer. My linker won’t allow me to create something that big. I think I still have enough ram left, but the ‘#pragma udata my_section_1’ trick will only allow me to define a buffer up to 256 bytes.
 
The AN1003 seems to be very happy in configuring the SPI just as, ‘OpenSPI(SPI_FOSC_64, MODE_11, SMPMID);’ . It doesn’t play a lot with the SPI config bits, like the ‘dragstar car’ example. I am worried that the SPI config issue may lead to a dead end.
 
It’s gotta be something! The board does work with the CCS 8 code.
Kruse
Super Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 18:46:13
Smack me if I'm wrong .. but SPI busses .. they do not use pull up's anywhere.
I2C bus uses pull up in dataline.
 
Maybe this could cause your additional 1's  (?)
 
BTW:I know that in some instances it is recommended to add low ohm's in serial with SPI lines to prevent lock up's.
meloware
New Member
RE: SPI returns partially bad data when reading SD memory block 2007/06/10 19:02:55
DO (data out), DI data in, and the chosen Chip select line are tied to a resistor pullup network. SD clock is not.
My opinion? Chip Select may be a good idea, but DO/DI may not be. In any case, this target board works well with the guy's precompiled code that was delivered in the chip.

I could deal better with the problem, if ALL the data was bad. But this is serial data, and the errors only appear on bytes whose binary addresses end in '100' and '101'. I also now realize that this problem is not just with memory block data, but even with reading things like the SD Card's CSD and CID registers.

I could be led to believe something is clobbering the data, but the only shared SPI lines from the MCU are the Data in and clock. Data in (the SD's data out)is also shared by the vs1011's data in, and the same chip shares the clock signal with the SD card.

spinnaker
Super Member
Re: RE: SPI returns partially bad data when reading SD memory block 2012/01/08 20:36:44
Hey meloware, Are you still out there? Did you ever solve this problem? I am pretty much getting the same issue as you. Every 7 and 8th byte is set to $0f and $04 then all bytes should be zero. Please respond if out there.