ALFAT rejecting version command over SPI?

File-System Hardware
1

I have an ALFAT-SD board which I’m trying to communicate with using the SPI bus. I’ve got it to initialise and I am (confirmed with a logic analyzer) reading the banner string back from the board. This suggests everything should be lovely.

Then I send the version command (‘V’, 0x0A); ALFAT responds with RFB == 1, but when I go to read the response, it’s all zeroes.

See the attached logic analyzer screenshot. The “\n” from the initialization banner is visible on the left side. Following is the V command write, then the attempts to read the response - 3 bytes at first, then 1 byte at a time.

I’m probably doing something wrong, but what?

– Rebecca

2

@ Phu -

You were doing a thing that is not recommend but I don’t think that is your problem. Basically I don’t see anything wrong from your analyzer.

  • Did you read all banner string (0x49 bytes) successfully?
  • What speed SPI are you using?
  • After sent “V\n” command, delay 1s then send only read header (0x2 0x3, 0x0), tell us your result
3

Hi Dat,

Scrolling through the analyzer I can the whole string was read, up to and including the trailing !00\n (the \n you see in the screenshot is from the last 4 bytes). I have not counted the exact number of bytes received, but it all appears to be there.

The PIC is running at 8 MHz, with manually bit-banged SPI. I’ve also inserted (for debugging purposes) delays between bit transitions so that it’s running at sub-1MHz.

I’ll check adding an extra long delay after sending the V\n command when I get back. I have the specified 4uS delay after writing the command before attempting to read the response back.

4

Testing with a 1 second delay (actually 1.6 seconds due to picking some arbitrary numbers for a delay loop) between the write frame of “V\n” and the read frame - no difference. Still coming back with zeroes.

5

Aha… I seem to have found the problem.

It appears the documentation is in error regarding the definition of “” aka “\n”.

On a whim, I tried changing 0x0A (line feed, LF, as given in the frame examples) to 0x0D (carriage return, CR). Lo and behold, “v1.0.2”.

It’s odd that it is expecting commands terminated with 0x0D, but returns responses terminated with 0x0A.

6

@ Phu -

This is super old version. you should update at least 1.0.8 or 2.0.0, both accept 0x0A or 0x0D at end of command.