Additional 0x0D before the module respond ?

[l.collet]

Hi,

I was previously using the following system to get the response of the uALFAT :

while(!SD_DATARDY);
while(SD_DATARDY)
{
    SD_GetChar();
}

And it was actually working quite well. But now I need to know if each command is successfull, so I tried to put the exact number of SD_GetChar that the uALFAT is supposed to send back and check them.

But looking carefully, I've seen that the first character I receive after sending a command is '0x0D' instead of '!', and then I receive the correct response.

Still, before I send my command, SD_DATARDY is low and I don't have anything to read back.

Moreover, it seems that I get the whole response in the previous command (I thought first that the uALFAT behave that way because I forgot to read the last char)

Any idea ?

Thanks in advance !

[SupportAdmin]

SPI, I2C?
Using latest firmware? What version?

It is easier keep reading while data is not 0xFF like shown in example library

[l.collet]

Sorry, I forgot to mention those details.

I'm using SPI, and firmware is 3.12

This particular issue seems to happen with "write" command. "Version" for instance doesn't seem to be affected.

I hope this will help.

[SupportAdmin]

You need about 1uS delay between every byte transfer

[l.collet]

Checking with a scope, I have about 6µs delay...

[SupportAdmin]

Before sending the command, keep reading till you see 0xFF and DATARDY is low, now send the command. Do you see /D in response?

Your probably have an error in your code somewhere

[l.collet]

DATARDY is low before I send the command.

If I try to read from uALFAT before I send the write command, it send 0xFF.

[SupportAdmin]

Then you should get !00<cr> after the command, any command. If you see anything else then SPI is not set right, clock is too high or you have a bug in code.