Hi Dave, I'll try to answer the best I can as I haven't worked on the init
proc in a while. First thing you should know is that we may not be working
with a card/circuit that is powered down. The card could be in read or
write state. I had trouble with a stuck card if I restarted the PIC without
power off. The extra code is for this purpose.
You said you read SAN DISK documentation, but you should also give SD Card
specification 2.0 a read. I think there is a 3.0 specification as well.
>> Prior to the main loop we see a CS low, wait 1 msec. ,CS high.
>> Can I ask why? What requirement does this address ?
-- steps to set sd card to use SPI
sd_chip_select = low -- start chip slect low
_usec_delay(1_000) -- delay
sd_chip_select = high -- chip select high
This is so the sd card starts in SPI mode to use the SPI bus instead of sd
card bus.
>> Then presumably the 10 FF's sent (note with the CS still high!) are to
cover the reference to 75 logical 1's sent on
>> CMD line as part of the card power up/ initializing sequence?
for 10 loop
spi_master = 0xFF -- send clock pulses (0xFF 10 times)
end loop
Yes, according to documentation, we are required to send some clock pulses.
The sd card may be doing something internally at this point such as
clearing a shift register.
>> However documentation says send logical 1's for larger of 1msec, 75
clock ticks, or supply ramp up voltage time.
>> By my reckoning even with FOSC at 4Mhz and SPI _RATE_FOSC_64, 80 clocks
ticks is only just over 1 msec.
>> Any other combinatons of FOSC and SPI_RATE_FOSC will be well under 1
msec.
>> Shouldn't we be doing 1 msec worth of logical 1's based on oscillator
and SPI clock speeds? As for supply
>> voltage ramp up time if it was known it could be an optional CONST or
parm for INIT and compared with 1msec/75
>> ticks? Am I over complicating this?
I'm not sure where you have seen this documentation about the 1ms of logic
1's, but I have no objection to changing this. Maybe SAN DISK has different
specs. You may show me some new code and what you wish to change it to.
There is an oscillator speed constant provided by the compiler or the
device files, I can't remember what it is.
>> Can I ask here about the response? Do we know that as a result of any
single CMD0 the card will have noted the
>> request, switched to SPI mode, delivered a meaningful response (in SPI
mode) and then gone idle. If so we
>> would expect the response to always show “idle state”. Can the response
to a CMD0 show anything but “idle
>> state”?
You'll have to check sd card spec for responses, I can't remember. From my
code, I can see response of 0 means it is not idle.
>> Again with CMD1, presumably the card response to the command could be
“in idle state (still)” but with the
>> understanding that it will get to a ready (non idle) state as soon as
possible after initializing.
The look will exit as soon as wee get one good response from
SD_GO_IDLE_STATE.
Part of the reason for this loop is to get the card is out of a read or
write status.
I actually have some code somewhere to init a high capacity card. I was
able to get a response from one of these, but was never able to read or
write to SDHC cards.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/jallib/-/ZDmoS68h5BIJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
