Lpc2000

Tom,
    Thanks for the comments. We are going to review it ASAP.
There are some issues in the sample source for sure, as you
pointed out in 80 clocks in mmc_init(). But, in mmc_write_block(), 
the first 8 bytes is not the actual data, but some dummy 
clocks before sending the actual command, followed by 512 bytes
of data. 
 
Regardless, I am going to look into that again and give you
all a satisfying answer.

Tom
Philips Apps.


--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> Perhaps someone who is better versed in MMC SPI stuff should take 
a good 
> look at Philips AN10406.  There appears to be some problems with 
the 
> example code it contains.  Two issues jump right out in the file: 
> spi_sd.c...
> 
> In mmc_init(), look at the _second_ for() loop:
> ======== begin mmc_init() ==========
> int mmc_init( void )
> {
>    DWORD i;
>    /* Write data pattern for testing */
>    for(i=0;i<MMC_DATA_SIZE;i++) {
>       MMCWRData[i] = i;
>    }
>    SDStatus = 0;
> #if !USE_CS
>    IOCLR0 = 0x00100000; /* clear SPI SSEL */
> #endif
>    /* Initializes the card into SPI mode by sending 80 clocks */
>    for(i=0; i<10; i++) {
>       MMCCmd[i] = 0xFF;
>    }
>    SPI_Send( MMCCmd, 10 );
> ======== snip =================
> 
> The sizeof(MMCCmd) is only 8 bytes, not 10.
> 
> While that is not too bad, it gets more interesting as you read 
the 
> mmc_block_write().  During mmc_init(), CMD16 has set the blocksize 
to 
> 0x200 (512 bytes), okay?  But, when they write the data during 
> mmc_block_write(), they only write 8 bytes.  Then they proceed to 
hold 
> the chipselect down and poll 255 times for a completion status 
code!  Of 
> course, it dies, while the MMC gets deadlocked waiting for the 
rest of 
> the data...
> 
> Another issue is that the mmc_write_block() does not look at BUSY 
from 
> the MMC, but assumes a delay loop is an answer to when a write has 
> completed!!!
> 
> With my understanding of MMC and the reading of the code in 
AN10406, it 
> looks as if mmc_block_write() is never going to write a block to 
the 
> MMC?  After compiling and debugging the code for a few hours, I'm 
> satisfied that there are problems with it (appnote code).
> 
> The night was not a total loss, working with the app note had made 
me go 
> back and take a critical look at the MMC spec + my code.  Heh, my 
code 
> is working flawlessly now!
> 
> IMHO, I strongly urge Philips to remove AN10406 from their website 
until 
> a code review has been performed.
> 
> 
> Regards,
> 
> TomW
> 
> 
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>