• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 631 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

sd card writing data

viney chaddha1
Expert 1280 points
Other Parts Discussed in Thread: MSP430F5529

Hi,

I am new to SD card. I want to write the data to SD card using MSP430F5529 LP using USCB1 for SPI. I plan to use the 8 GB card hence the initiallization is different for that rather than the one given in the driver code through SLAU281. I changed the init sequence to CMD0, CMD55, CMD41, CMD58, CMD 55 and CMD41 together form ACMD41. Now this would mean that i need to write my data in the block of 512 bytes: 

My questions:

1. If i get data in form of 32 byte block and I write the 32 bytes that i receive - what happens to the balance 480 byte of the block?

2. How to pick up the address for writing the blocks of 32?

These questions may sound trivial but being new to this they are foxing me. Any help with a sample code would be appreciated.

Also as a next step I want to put data in FAT format. what kind of glue-code should be written for integrating Elm-Chan's FatFs program, a sample code would be of great help.

Regards

Viney Chaddha

  • 0
    Guru 99605 points
    The controller inside the card must pre-erase the block, so if you could write a short block the remainder would be erased.

    That said: The controller protocol expects 512 bytes followed by two extra (CRC) bytes. If you were to simply deassert (raise) /CS after 32 bytes, i.e. in the middle of a transaction, I suspect the controller would treat this as a protocol error and not write anything. (I haven't tried this.)

    SDHC (block rather than byte addressing) doesn't provide for addressing/updating inside a block. You can "update" a block by reading it (all), overwriting some of the data, then writing it back out, but at a low level this is really just like writing a fresh block.

    It is possible to run the SD card "hot", i.e. start writing a block then go off and leave it (with /CS still asserted) until you have more data. This leaves the controller inside the card active, and so is a power-intensive method but it can be useful if you don't have 512 bytes of SRAM to spare.
  • 0 in reply to Bruce McKenney
    Expert 2110 points

    The LP5529 EVB have exemples with uSD on the TI web site. (I just do not know if they permit 8GB uSD, I only tested it with a 2GB uSD card)

  • 0 in reply to MichRFT
    Expert 1280 points
    Thanks Bruce,
    I think i wasn't very clear on the block size and its question, what i wanted to know was:
    1. If I don't set block length then by default it is 512 byte. Now if I write a data of say 32 bytes and again I want to write data of 32 byte then in between two blocks of 32 bytes would I see 0x00?
    2. In case I would see 0x00 but want to avoid seeing that and want to read the written data a a continuous stream without having unintended 0x00 then how do I track the address of every subsequent block of 32 bytes?

    Mich,
    The code is essentially for MMC and what ever i read is that the initialization is different for the SDHC card. The code follows the initialization sequence for an MMC card.

    Regards
    Viney Chaddha

**Attention** This is a public forum