SPI Interface Tx pin issue on whitebeet-ei

[ElectronicMinds-uk]

I have found that tx_ready pin deasserts once during the first transaction and then remains asserted constantly after that.

This may be because there is always one transaction outstanding due to the way SPI works. Is there a "null" transaction that will not result in a response? Even the ping requires another transaction to get the ping return.

[bbr-stx]

Thank you for the detailed description. I will have a look at the problem soon.

[bbr-stx]

Hi, when reading the response from the Whitebeet module, the host can also send the length 0 during the SPI transfer ('size exchange frame' => AA AA 00 00). Then the host must read only the number of bytes that the module wants to send (received from host in 'size exchange frame' for example AA AA 00 08). For the data transfer the host should then simply send zeros in the data frame (for exampe 55 55 00 00 00 00 00 00 00 00 00 00).

After no command was sent to the module the TX pin should go low. If it does not go low, the host should again make an SPI transfer with data length 0 to read another packet from the host.

BR

[bbr-stx]

I assume that the problem has been fixed by now. If the problem is still not solved, you are welcome to reopen the ticket.

[ElectronicMinds-uk]

Hi,
I have investigated this further and implemented your suggestion. Unfortunately it has created another problem. I attach a listing of the SPI traffic. As you can see the whitebeet has an incorrect packet with repeated start of frame transactions

[ElectronicMinds-uk]

The problem happens after line 21 where the host is trying to get the packet 03. I cannot get past requesting the third packet whilst using the "null" packet as suggested.