I am using the USB SD board and I want to use it with SPI.
The “V” command (Get Version Number) and “J” command (Read Status Register) work fine, but I cannot initialize and mount the SD card with the “I” command.
I found that the RFB ALFAT response is not right with the “I” command. I miss two RFB (blue signal)! Decreasing the bus frequency and tracking the SPI_BUSY state was not successful.
Any suggestions?
Thank you very much!
Looking at I command trace, it looks like the LSB byte has a corresponding response byte of 0x00, which signals that ALFAT is not ready for MSB. If that is true then the I command must be terminated and the I command must be re-tried until the recieve byte corresponding to LSB is 0x01.
As I am new with ALFAT and SPI, I will check with another engineer to confirm
All commands are handled similarly. The only difference between V and I commands is that V responds immediately but I needs time to finish initializing the media.
To test this, send the command, wait a second and then read the response. If this works then you are not handling SPI properly, meaning you read but SPI has no data for you yet.
OK, thank you for the quick reply.
Now I stop sending the command, if I get not 0x01 with the LSB or with other data.
But If I repeat sending the command, my function stops always at “IM”. I can not send the “:”.
The problem is, that I can not send the whole command.
At this point, I do not try to read any data e.g. "!00"
It is very strange. When I repeat sending the command, I get 0x02 as “Ready Flag Byte” and not 0x01. But checking my SPI connection and protocol seems OK.
As bytes are sent, the ALFAT processor may signal the host to stop sending bytes. The primary method that should be monitored by the master is the SPI_BUSY (I2C_SCL) pin high. During the sending of header bytes, the frame Type byte should be written, then the LSB byte. If the return value corresponding to the LSB is zero or SPI_BUSY is high, the entire frame must be restarted. Once the last byte of the header (MSB) is sent, the SPI_BUSY pin is read; if it is high, the master must idle; when low, the next byte is sent. This process of send payload byte, check SP_BUSY is continued until all the payload is sent. ALFAT has an internal buffer that is 4Kb, if the payload length is less than or equal to 4Kb, the entire payload may be sent in one Write frame, without checking SPI_BUSY.
@ Mr. X -
Let me read whole data you send, please. I mean frame header + raw data.
The FRB is second byte that is returned from ALFAT when you sent first 2 bytes of write header. if that byte is OK, because “I M:” is smaller than 4KB, so you don’t need to care the rest.
Why you can not send them? Even if you monitor by Busy Bin, busy pin state is also ready in this case. So there is no reason that let you can not send these bytes.
And try to add delay 4us for each byte transferred.
In fact, RFB is busy when
When ALFAT boots up / reset, or there wasn’t any command that related to USB/SD, RFB should never be busy.
So try:
case 1:
Case 2:
All right, thank you for the support. Firmware is v1.0.8.
Because of the picture in the datasheet, I thought each byte I sent must reply with RFB = 0x01. :wall:
My function stops data output, if ALFAT is not 0x01 returning. I have updated my function and it seems that it works now. The “Write Frame” chart was very helpful, is it also available for the “Read Frame”? You should add these charts to the datasheet.
Now I am struggling with opening a new file in the root directory, but it is too early to ask for it. I have to test something.
But so far, many thanks for the support! : 
Yes, I also like that charts, thanks Jeff.
[quote]Because of the picture in the datasheet, I thought each byte I sent must reply with RFB = 0x01. :wall:
My function stops data output, if ALFAT is not 0x01 returning.[/quote]
As I said, RFB is only second byte that was returned from ALFAT when you sent 2 first bytes of header. These rest bytes are not important if block size is smaller than 4KB because they are always 0x1. If any of them is not 0x1, then your master SPI still have bug with reading.