IVP
2015-02-11 23:58:09 UTC
Hi all,
I'm having a wonderfully frustrating time with a variety of SDHC cards
The same code which works very well with one fails to varying degrees
with others. I have two samples of each. All are readable in a PC card
slot except the Silicon Power, which I think might be crap and wonder
if they support SPI anyway. A couple of the 4GB seem OK in a camera
Strontium 8GB, everything works
Silicon Power 8GB, abject failure (one won't even format)
Sandisk 4GB, doesn't complete initialisation (endless ACMD41 loop)
Panasonic 4GB, ditto
Unknown brand 4GB, initialises but won't read more than 1 block
The last is the particular problem I'm tackling and wonder if anyone
has any ideas. Initialisation is at 250kHz, switching to 11MHz for
normal operation
Loading Image...
Loading Image...
As you can see in the analyser screens, the PIC (dsPIC33) first reads
Sector 0, then calculates which absolute Sector FAT is pointing to. In
this case, the partition from hidden sectors starts at Sector 0x2000.
is successful as I can see the file names on an LCD and retrieve them
as data. The Strontium is also in another application and will quite
happily run for hours and hours pulling data without a glitch. It's that
application which I'm modifying just to keep the problematic project
moving forward
For some reason, the Unknown brand doesn't send an 0xFE token on
the second CMD17, which is trying to read Sector 0x2000. Below is
the relevant section of the s/w.
I've tried repeating the CMD, flicking CS, delays, dummy data sends
with no difference. Some of those stuff up operation of the only working
cards, the Strontiums
Vcc is a good steady 3.29V, plenty of ceramic and bulk caps, pull-ups
on Dout, Din, Data2 and Data3. No noise apparent
The sensible me says buy more Strontium. The stubborn me wants to
find out why some cards don't work properly (which may pay dividends
in the future even though 4GB cards will probably become scarce). At
the moment I feel it's wasted effort to get the 4GB working when 8GB
are readily available (Silicon Power notwithstanding) but I'd still like
to get to the bottom of it, if there is a bottom
Help
TIA
Joe
-------------------------------------
read_fat: clr sec_adr_lo ;read sector 0
clr sec_adr_hi
mov #ram1,w8 ;into PIC RAM
call getblock
;find Boot Sector / Root Directory
clr offset ;default, no offset
mov ram1,w0 ;read first byte of sector 0
bra nz,boot ;<> 0 (E9 or EB)
;if 0 at sector 0 then look for Boot Sector
;MBR + partition, read 0x1c6 - 0x1c9
partition: mov ram1+#0x1c6,w0 ;fetch 0x1c6 and 0x1c7, LSW
mov w0,sec_adr_lo
mov w0,offset ;offset <> 0
mov ram1+#0x1c8,w0 ;fetch 0x1c8 and 0x1c9, MSW
mov w0,sec_adr_hi
mov #ram1,w8
call getblock ;read sector pointed to by
0x1c6-0x1c9
;--------------------
getblock: mov #0xff,w0
call send_w0_f
mov #cmd17,w0 ;read block
call send_w0_f
mov sec_adr_hi,w0 ;block number <31:16>
swap w0
call send_w0_f
swap w0
call send_w0_f
mov sec_adr_lo,w0 ;block number <15:0>
swap w0
call send_w0_f
swap w0
call send_w0_f
mov #0xff,w0 ;dummy CRC
call send_w0_f
gettoken: mov #0xff,w0
call send_w0_f
bclr SPI1STAT,#SPIROV
btss SPI1STAT,#SPIRBF
bra $-2
mov SPI1BUF,w0
mov #0xfe,w1
xor w1,w0,w0
bra nz,gettoken
send_w0_f: mov w0,SPI1BUF ;load data into SPI buffer
call usec ;wait at high speed (some dsPIC
SPI
flags are broken)
return
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5646 / Virus Database: 4284/9097 - Release Date: 02/11/15
I'm having a wonderfully frustrating time with a variety of SDHC cards
The same code which works very well with one fails to varying degrees
with others. I have two samples of each. All are readable in a PC card
slot except the Silicon Power, which I think might be crap and wonder
if they support SPI anyway. A couple of the 4GB seem OK in a camera
Strontium 8GB, everything works
Silicon Power 8GB, abject failure (one won't even format)
Sandisk 4GB, doesn't complete initialisation (endless ACMD41 loop)
Panasonic 4GB, ditto
Unknown brand 4GB, initialises but won't read more than 1 block
The last is the particular problem I'm tackling and wonder if anyone
has any ideas. Initialisation is at 250kHz, switching to 11MHz for
normal operation
Loading Image...
Loading Image...
As you can see in the analyser screens, the PIC (dsPIC33) first reads
Sector 0, then calculates which absolute Sector FAT is pointing to. In
this case, the partition from hidden sectors starts at Sector 0x2000.
From there, the s/w pulls out the directory and accesses files. Compare
with the Strontium reading 3 blocks with no problem. Directory readis successful as I can see the file names on an LCD and retrieve them
as data. The Strontium is also in another application and will quite
happily run for hours and hours pulling data without a glitch. It's that
application which I'm modifying just to keep the problematic project
moving forward
For some reason, the Unknown brand doesn't send an 0xFE token on
the second CMD17, which is trying to read Sector 0x2000. Below is
the relevant section of the s/w.
I've tried repeating the CMD, flicking CS, delays, dummy data sends
with no difference. Some of those stuff up operation of the only working
cards, the Strontiums
Vcc is a good steady 3.29V, plenty of ceramic and bulk caps, pull-ups
on Dout, Din, Data2 and Data3. No noise apparent
The sensible me says buy more Strontium. The stubborn me wants to
find out why some cards don't work properly (which may pay dividends
in the future even though 4GB cards will probably become scarce). At
the moment I feel it's wasted effort to get the 4GB working when 8GB
are readily available (Silicon Power notwithstanding) but I'd still like
to get to the bottom of it, if there is a bottom
Help
TIA
Joe
-------------------------------------
read_fat: clr sec_adr_lo ;read sector 0
clr sec_adr_hi
mov #ram1,w8 ;into PIC RAM
call getblock
;find Boot Sector / Root Directory
clr offset ;default, no offset
mov ram1,w0 ;read first byte of sector 0
bra nz,boot ;<> 0 (E9 or EB)
;if 0 at sector 0 then look for Boot Sector
;MBR + partition, read 0x1c6 - 0x1c9
partition: mov ram1+#0x1c6,w0 ;fetch 0x1c6 and 0x1c7, LSW
mov w0,sec_adr_lo
mov w0,offset ;offset <> 0
mov ram1+#0x1c8,w0 ;fetch 0x1c8 and 0x1c9, MSW
mov w0,sec_adr_hi
mov #ram1,w8
call getblock ;read sector pointed to by
0x1c6-0x1c9
;--------------------
getblock: mov #0xff,w0
call send_w0_f
mov #cmd17,w0 ;read block
call send_w0_f
mov sec_adr_hi,w0 ;block number <31:16>
swap w0
call send_w0_f
swap w0
call send_w0_f
mov sec_adr_lo,w0 ;block number <15:0>
swap w0
call send_w0_f
swap w0
call send_w0_f
mov #0xff,w0 ;dummy CRC
call send_w0_f
gettoken: mov #0xff,w0
call send_w0_f
bclr SPI1STAT,#SPIROV
btss SPI1STAT,#SPIRBF
bra $-2
mov SPI1BUF,w0
mov #0xfe,w1
xor w1,w0,w0
bra nz,gettoken
send_w0_f: mov w0,SPI1BUF ;load data into SPI buffer
call usec ;wait at high speed (some dsPIC
SPI
flags are broken)
return
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5646 / Virus Database: 4284/9097 - Release Date: 02/11/15
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist