I have been trying to figure out how to use Microchip's SPI library.

I understand the secret to configuration is in HardwareProfile.h

They ask for a card detect pin and a write protect pin configuration on the Pic. Well looking at the pinout for a SD chip in SPI mode, it does not have a card detect or write protect pin.

Looking at the code there seems no way to make these pins optional. How do I handle this?

 

Both the Card Detect and the Write Protect signals originate not with the SD card, but with the SD card socket.

If you are not using these features (assume card always there, assume always correct (incorrect) to write) then just set the defines for these pins to give a TRUE or FALSE as appropriate.

 

But the library tries to initialize TRIS and such.

I have 9 pins on my socket. One pin for each of the SD memory connectors. There are other sockets with more pins?

Since the write protect switch is on the SD itself. Wouldn't the SD have to provide a pin?

 

The socket has a little lever that pokes in to feel the card write protect switch. Not really microswitches but piece of metal that no longer touch when a card is inserted it will open if card is inserted and stay open if write protection is enabled. See if one of your pins reads ground when card is inserted, and floating when not or vice-versa.

SDHC is what nearly all cards are now, WP isn't a physical switch. It is a setting on the card itself.

Mostly unused except in cameras which will "lock" a card.

From the datasheet:

                                       Table 5. Card Detection Approaches 

                                                                                            SD/SDIO Card     MMC 
 Method     Approach                             Brief Description 
                                                                                               Support      Support 

    1       Mechanical   Insertion can be sensed by mechanical detecting the WP switch           Yes          Yes 

    2        Electrical  Insertion can be sensed using the pull-up resistor on DAT3              Yes           No 

    3        Software    Periodical attempts to initialize the card                              Yes          Yes 

The Mechanical approach is the most common approach and is independent of the MMC/SDHC. Only a 
card socket is used with a mechanical design and is connected to a GPIO pin of the i.MX21 processor, the 
card detection is made by an interrupt trigger from the GPIO pin. 

The Software approach is a less common approach because of increased power consumption. This 
approach will not be discussed in this document. 

The Electrical approach is MMC/SDHC dependent and is supported by the MMC/SD host controllers in 
the i.MX21 processor. When using this feature, the user must use care with the pull-up/pull-down resistor 
Card Detection
connected to DAT3 line. Moreover, the following software implementations must occur: (See also 
Figure 4.)
a) The internal pull-up resistor must not be enabled when there is no card inserted.
b) There must be an external pull-down resistor connected to DAT3 and this pull-down resistor 
can be disconnected by software. The suggested value is 750 kohm.
c) For an SD memory card, after the card detection phase, ACMD42 must be issued to 
disconnect the pull-up resistor inside the card, which is connected to DAT3.
d) For an SDIO card, after the card detection phase, ACMD52 must be issued to clear the CD 
Disable bit in Bus Interface Control register (address: 0x08) in the CCCR to disconnect the 
pull-up resistor inside the card, which is connected to DAT3.
e) For a combination of cards, both items c and d must be implemented. Otherwise the 
card-internal pull-down resistor will not be disconnected.
f) After disconnect the card-internal resistor, then:
ó Disconnect the external pull-down resistor to DAT3 line (Note 8 in Figure 4).
ó Enable the i.MX21 internal pull-up resistor for DAT3 pin (Note 9 in Figure 4).
g) The card identification can be started.


9 Reference Documents
The following documents are helpful when used in conjunction with this application note.
[1]: MC9328MX21 Reference Manual (order number MC9328MX21RM/D)
[2]: SD Memory Card Specifications, Part 1 Physical Layer Specification Version 1.0
[3]: SD Memory Card Specifications, Part E1 Secure Digital Input/Output (SDIO) Card Specification,
Version 1.00
[4]: The MultiMediaCard System Specification, Ver s ion 2.1
The Freescale manual is available on the Freescale Semiconductors Web site at http://www.freescale.com/imx. 
This documents may be downloaded directly from the Freescale Web site, or printed versions may be ordered.

 

But the library tries to initialize TRIS and such.

I have 9 pins on my socket. One pin for each of the SD memory connectors. There are other sockets with more pins?

Since the write protect switch is on the SD itself. Wouldn't the SD have to provide a pin?

The switch on the SD card (I've only seen these on the original large size units) is just a mechanical slide piece with no electrical connections. The socket detects the position of the switch. Similarly the card detect line senses if the card itself is in the socket. Both use metal contacts as thatoneguy describes.

The sockets I've seen have 11 pins, the 2 "extras" to handle card detect and write protect. Example of SD card with 11 pins.

If you are not using these two signal lines (which I do not recommend if they are available) then your hardware profile could look something like this:

        #define Dummy_Reg TMR1L     // grab Timer1 as dummy write destination

        // Card detect signal
        #define SD_CD               FALSE       // always sense pin low
        #define SD_CD_TRIS          Dummy_Reg   // to do a dummy write
        
        // Write protect signal
        #define SD_WE               FALSE       // always sense pin low
        #define SD_WE_TRIS          Dummy_Reg   // to do a dummy write

Due to the way the MDD_SDSPI_InitIO() function in SD-SPI.c is written we need to give it a place to write the TRIS assignments even if we don't use them.

 

Thanks a lot Ernie.

Do you (or anyone) happen to have a sample schematic of something you know that works?

I have seen such combination of pullups and caps and inductors on the VDD it would make your head spin. Part of my problem here is there seems to be way too may variables.

 

If you look here there is one example. CN4 to the bottom left of the butterfly is the SD card socket. OK, it uses a PIC32 but the connections are the same. I did not notice any inductors in series with the power but it's not a bad idea (just may not be absolutely necessary).

Do note the PIC is running off 3.3 volts. If you're using 5V then you'll need some interface to do the level translation.

One more thing to look at is AN1045

 

My pic is 3.3v so levels won't be an issue.

Thanks for the links.

I think I figured out the whole chip detect and write protect thing.

The socket has two weird tabs. Those are the chip detect. then between the case and one of the tabs is the write protect.

And the switch for write protect works exactly as you said. It is a mechanical think that pushes on springed metal.

 

That sounds right. The socket case is grounded so that is how the device detect and write protect detects both work, they connect to case and thus ground.

 

Slight change in how chip detect and write protect work.

Looks like case should be ground. Outside strange tab is write protect. Inside pin is chip detect.

I always have trouble reading those schematics where they group the bus lines.

Do I read that right that there are only 10K pull ups on chip select, SDI of the chip, write protect and chip detect? Rest are connected to the MCU with no pullups?

 

Do I read that right that there are only 10K pull ups on chip select, SDI of the chip, write protect and chip detect? Rest are connected to the MCU with no pullups?

Yep, that is correct, though I don't see why chip select CS needs a pull up, it is a PIC output pin. Using it can't hurt to cover the brief time bewteen power up and card init.

They also have a LED connected to that pin so when CS goes low (active) the LED turns on; it's a nice way to get a simple but effective card activity indicator.

 

So no pullup needed on Chip Select?

or is that done via the led??

 

Yes the LED acts as a pull-up, so I don't see any huge requirement for a pull up on the chip select. So that makes it a judgement call.

Personally I would leave the resistor out.

 

I am still very confused by this SD Memory Library,

The HardareProfile. h file has the following defines
<code>
// Defines for the HPC Explorer board
#define SPICLOCK TRISCbits.TRISC6
#define SPIIN TRISBbits.TRISB2
#define SPIOUT TRISCbits.TRISC7

// Latch pins for SCK/SDI/SDO lines
#define SPICLOCKLAT LATCbits.LATC6
#define SPIINLAT LATBbits.LATB2
#define SPIOUTLAT LATCbits.LATC7

// Port pins for SCK/SDI/SDO lines
#define SPICLOCKPORT PORTCbits.RC3
#define SPIINPORT PORTBbits.RB2
#define SPIOUTPORT PORTCbits.RC5
</code>


It looks like it wants to bit bang the SPI port but HardwareProfile.H also has defines for the SPI module.

The latches and ports are used in functions ending with manual. Which looks like the big bang version of the SPI module functions.

I want to use my SPI module.

 

Oh don't be such a baby and just use the library as it is.

A few one time only initialization functions get bit banged.

All subsequent data transfers are done thru the module.

 

A few one time only initialization functions get bit banged.

All subsequent data transfers are done thru the module.

I don't think so. From the looks of the code it is bit banging all the way,

But maybe I will give it a try anyway.

 

Go look at the comments for WriteSPIManual() in SD-SPI.c Might as well peek at WriteSPIM() there too.

 

Go look at the comments for WriteSPIManual() in SD-SPI.c Might as well peek at WriteSPIM() there too.

OK it says

This function replaces ReadSPI, since some implementations of that function
will initialize SSPBUF/SPIBUF to 0x00 when reading. The card expects 0xFF.
This function is for use on a PIC18 when the clock speed is so high that the
maximum SPI clock prescaler cannot reduce the SPI clock below the maximum SD card
initialization speed.

But my clock speed is pretty low. Do I still need to use these functions?

 

Once you add FSIO.c, SD-SPI.c and salloc.c to your project you have no need to call these functions directly, the library will pick what is most appropriate and use that.