This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

msp430f5438 - writing on SD card (slaa281b)

Other Parts Discussed in Thread: MSP430F5438

Hello all,


-We want to communicate SD card with MSP430F5438. We are using the slaa281b example code on TI website, that we also modified it for F5438. In this source code, it uses Card Detect (CD) that we want to cancel, can CS be used on behalf of CD? Should we directly neglect the CD pin configuration?

-Besides, if we want to send data to SD card, do we need to create a text file? Does this code generates a file or just sending bytes? How can we test to send/receive data with SD card?

-Lastly,  are these codes work for MSP430F5438? It should not work as UCTL0 register, that is equivalent to UCA0CTL0 in our MCU. However, it does not give any compiling error in IAR. What can be the reason of this?
  UCTL0 = CHAR + SYNC + MM + SWRST;         // 8-bit SPI Master **SWRST**
  UTCTL0 = CKPL + SSEL1 + SSEL0 + STC;      // SMCLK, 3-pin mode

  • Levent Erb��k said:
    In this source code, it uses Card Detect (CD) that we want to cancel, can CS be used on behalf of CD?

    No.

    CD is a signal that is (externally) pulled to VCC by a resistor and shorted to GND by a switch when you insert the card. It tells the code that a card was inserted or removed. It's a purely machanical thing and if this signal is available at all depends on the SD card socket you use.

    CS is a data signal that tells the card that you want to begin a data transfer (send it a command and then read or write data)

    Levent Erb��k said:
    if we want to send data to SD card, do we need to create a text file? Does this code generates a file or just sending bytes?

    It just sends or reads data to or from a specified data sector on the car. It is raw low-level media access, no file system, no knowledge at all about what may or may nto be on a specific sector of the card.

    If you want to work with files on the card, you'll need additonal software that provides a file system and uses the SD card sample code for reading and writing the raw data sectors.

    Levent Erb��k said:
    are these codes work for MSP430F5438? It should not work as UCTL0 register, that is equivalent to UCA0CTL0 in our MCU. However, it does not give any compiling error in IAR. What can be the reason of this?

    The code is IMHO written for the 1x family USART module (also available in some 4x family devices).
    The control bits used in the USART for SPI are the same as in the USCI. However, there are differences. I'm surprised that UCTL0 (wasn't it U0CTL?)  is accepted as alias for UCA0CTL0.

    It's possible that the code will work, because most of the differences are with interrupt handling, which isn't used in the MMC/SD demo code at all.

    However, the only differences to expect are int he low-level SPI code and not in the mid-level MMC/SD code.

    Nevertheless, the TI code is only a starting point. I found it incomplete and fragile and only used it as a starting point for my own implementation.

  • Thanks Jens, one more question though, do SD cards have seperate CD pin in SPI mode? We are connecting DI,DO,SCK and CS pins to MSP430, with also Vcc and 2 Gnd pins. We could use a pull-up resistor, but could not find any pins to associate with.

    We have also tried to get the code working in the functions that have UCTL0 register, then it had some compiling errors, however we have changed all the flag and control registers. I think that our problem is that the code never goes into those functions before.

  • The CS signal is multiplexed with one of the data pins from parallel mode. (I think it's DAT3)
    If during reception of the initial CMD0 this data pin is held low by the master, the SD card will enter serial mode and this pin will act as CS pin until next power cycle. If it is left open (pulled-up by the card), the card will be in parallel mode. You can always switch from parallel to serial mode, but not back again.

  • Forget what I wrote, I misread the question.

    The CD pin (not CS) is not connected to the card. It is a switch on the card slot and operated by the card (closed to GND when the card is inserted and open when there is no card inserted).

    Not all card slots implement it. If yours doesn't, you'll have to just try every now and then to init a card that may or may not be there.

  • Hi again,

    Jens-Michael Gross said:
    If you want to work with files on the card, you'll need additonal software that provides a file system and uses the SD card sample code for reading and writing the raw data sectors.


    We have used Elm Chan's FatFs and modified with SPI interface with the help of this code. The result does not create any files, read or write them. When we debug, we see that it stucks and returns as disk initialization problem. Can there be a problem in Elm Chan's code, despite being used world wide as we can see? Or is there something wrong with our SPI initialization and declarations?

    #define CSPORT         P3OUT            
    #define CLKPORT        P3OUT           
    #define DIPORT         P3OUT            
    #define DOPORT         P3IN
    #define CS              1<<3          
    #define CK              1<<0            
    #define DI              1<<4            
    #define DO_             1<<5           
    #define    CS_H()        CSPORT |=  CS    
    #define CS_L()        CSPORT &= ~CS    
    #define CK_H()        CLKPORT |=  CK    
    #define    CK_L()        CLKPORT &= ~CK    
    #define DI_H()        DIPORT |=  DI    
    #define DI_L()        DIPORT &= ~DI    
    #define DO              DOPORT & DO_  


    void spi_init (void)
    {
      UCA0CTL1 |= UCSWRST;                      // **Put state machine in reset**
      UCA0CTL0 |= UCMST+UCCKPL+UCMSB+UCSYNC;    // 3-pin, 8-bit SPI master
                                                // Clock polarity high, MSB
      UCA0CTL1 |= UCSSEL_2;                     // SMCLK
      UCA0BR0 = 0x02;                           // /2
      UCA0BR1 = 0;                              //
      UCA0MCTL = 0;                             // No modulation
      UCA0CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**
      UCA0IE |= UCRXIE;                         // Enable USCI_A0 RX interrupt
    }

    void spi_send_byte(char spi_data)
    {
        while(UCTXIFG == 0);
        UCA0TXBUF = spi_data;
    }

    char spi_get_byte(void)
    {
        spi_send_byte(0xff);              
        return spi_data;                
    }

  • Hmmm, I'm nor sure what you've done here.

    The defines seem to indicate that it is for a software SPI (No P3SEL defines for switching the SIMO and SOMI and SCl pins to module mode, btu defines for extracting DO and DI from DIPORT and DOPORT)

    The two funcitons you defined for sending and receiving a byte through SPI are there, however, spi_get_byte gets - what? It returns spi_data which is undefined in the code you posted and definitely not what the hardware SPI has received.

    The wait for (UCTXIFG==0) is void, since UCTXIFG is a non-zero constant. It should be "while(!(UCA0IFG & UCTXIFG));" So you're overwriting TXBUF byte after byte without waiting for the previous byte being sent.

    SPI_get_byte, however, should clear UCRXIFG before calling spi_send_byte, then wait for UCRXIFG being set and then return the content of UCA0RXBUF.

    One more thing: during initialization, the maximum SPi baudrate for SD cards is 400kHz. Only after initialization, baudrate may be rised to up to 25MHz. But your code seems to start with SMCLK/2 form the beginning, which is most likely way more than 400kHz.
    (tip: don't go for maximum speed before it isn't working on lower speed at all.)

**Attention** This is a public forum