I am using the BW16 to relay a data stream received from 5GHz wifi (in promiscuous mode) to the SPI. Each packet is about 400 bytes. I use a handshake line from the SPI receiver to acknowledge each transfer.
My development environment is Arduino SDK 3.1.5 and I am currently using the Arduino SPI.h library.
The picture below is a general view of the SPI activity, here showing 8 packets.
However, as the Handshake line shows, there has been something weird happening on the very first edge of the Slave Select (here called HSPI_CSn). Below is a zoom on this first edge:
What it shows is a short Slave Select glitch occurring just after the first byte, just 250 ns wide here, but can be as wide as 1.2 µs. Because of this, the entire packet is corrupted and lost.
As I was using SPI in mode 0, I first thought this was a misbehavior of the hardware logic that allows Slave Select to toggle between each byte, as described in UM400 §184.108.40.206. As this mechanism is specific to Clock Phase (SCPH)=0, I then switched to mode 1, i.e. SCPH=1. Unfortunately the behavior is the same, and the glitch remains.
Weirdly enough, this situation is not permanent. I can have entire sessions without the glitch, whether in mode 0 or mode 1. And other sessions where the glitch won’t disappear, even after software updates and reboots. Unfortunately until now I have not been able to identify a deterministic method to make it appear.
From the SPI.h library I cannot play with the raw SDK’s
SSI_SetSSTogglePhase() function, because I have no hook to
SPIClass::pSpiMaster. Even then, I doubt it would solve my problem, because the
SSTOGGLE bit of the RTL8720’s
CTRLR0 register is already initialized to
SPI_SS_NOT_TOGGLE, which means that SPI supports continuous transfers without toggling Slave Select in mode 0.
Now I’m a little bit stuck in the dark. Any help appreciated !