ALFAT SoC Processor

Just started debugging the ALFAT Soc Processor part of an embedded design. After resetting the SoC Processor and initializing for SPI, I tried the V command. The first time, it returned this descriptive header:

  GHI Electronics, LLC
  ALFAT SoC Processor

Only by issuing the V command a 2nd time did it return the actual version (v1.0.8). Can anyone explain this? I didn’t see any reference to it in the manual.

1 Like

The first thing to do is to read out the banner being sent, before sending commands.

Welcome to the community.

1 Like

Ok, sounds like an addition to the next version of the manual.

So I did a Read Transaction to get the banner, and then followed by retrieving the Version. I’m using SPI. After the Write Transaction, I had to repeat the Request Frame of the Read Transaction several times before data was available to read.

Is this (repeated polling) the suggested approach to dealing with the response delay, or is there a better way (hardware or software) to determine when command processing has completed and response data is available?

There are 2 pins to help in these cases, ACTIVE and BUSY.

Per the manual (with SPI), ACTIVE goes low AFTER the master reads the response so that won’t help me to know when the send buffer is ready with the needed response data.

Also per the manual, the SPI_BUSY simply indicates when you can’t send anymore data to the ALFAT. Is there another BUSY pin I’m missing?

Do either pins have other functions not described in the manual? If so, please steer me to an example.

@ LarryG -

  • No way to know that ALFAT TX’s buffer is ready or not, except you send a SPI read transaction and check byte 2nd and 3rd. The Active pin will tell you both cases, the command is being processed or ALFAT TX’s buffer is not empty.

=> Yes, that is it.

Ok, sounds like the answer is to poll until response data is available (ouch!).

Please consider a firmware change to make the ACTIVE pin configurable so it can go low when response data is available. That would really help those of us with an SPI or I2C interface.

So in my testing with repeated response polling, I tried sending 3 byte Read Request Frames (Requested Transaction size set to 0). When I’d finally get the Payload size returned to me, I’d do the real Read Transaction (Requested Transaction size set to actual Payload size). But I found that the Payload returned didn’t include the error response, and it was necessary to poll again to get it. Will all the commands work that way or is the ‘poll with 0 Requested Transaction size’ to be avoided?

@ LarryG -

Send 3 byte Read Request Frame, check the 2nd and 3rd bytes, if they are zero, you can cancel this transaction. But if they are not zero, you MUST to send stuffing bytes to read ALFAT returned. Do not send Read Request Frame again if the actual size is not 0.

And the size of stuffing bytes should be <= actual size.
Why do you need error response?

I think it is not correct, there is no “poll with 0 Requested Transaction size”. You should send the size you want, ALFAT will respond how many bytes it has. If it is 0, of course you can not read any thing, you should cancel and re-send 3 bytes Read Request Frame again. Of it is not 0, you MUST send stuffing bytes to read raw data. User Manual page 16 explained about this.

After working with several more commands, I’m seeing quite a range of delays, between sending and being able to retrieve the final error response, that’s obviously command dependent. Can you provide info regarding typical delays for the various commands (or at least for those commands with the greatest delays before the error response is available)?

@ LarryG -

For SPI interface, it requires 4us delay for between 2 bytes which was explained in user manual.
For ALFAT commands, it hard to say how much it should be. Example, you send V command, delay value maybe very short, but Q (format command), it is really depends on how good / what size your device is.