We are using a murata SN8000 module connected via SPI mode 0 operating with 25Mhz to a cortex m3 lpc1837. We are using a WWD ported from the SDK 3.1.2 (including matching patch from murata). We are using a custom PCB with SPI Flash, SDRAM, MSU and SN8000. The MCU is operating with 180MHz. We are using an older version of freertos and LWIP (not taken from the SDK). The SPI interrupt has the second highest interrupt priority and SPI DMA has the highest interrupt priority. The wwd task has the highest priority as a task. There should be no long interrupt processing during the test.
During initialization we experience reproducable timeouts of ioctl commands issued after the firmware download.
The wwd_bus_init() function completes successfull but the further ioctl interactions of wwd_management_wifi_on() fail on different calls (timing dependant). An oscziloscope trace shows that after a couple of commands the SN8000 does not singal a SPI IRQ anymore.
The initialization function returns "Could not set AMPDU parameters" with an errorcode 2 (timeout).
The error does not occure at every start and if initialization completes successfully the SPI communication seems to work allowing conifguration of the WLAN module and exchange of data. Modifications of the timing make the error appear on different ioctl calls within wwd_management_wifi_on(). The traces show half completed communication sequences with missing SPI IRQ after a couple of successfull communication sequences with interrupts from SN8000.
If we continously using IOCTLs (by calling wwd_wifi_get_rate() in a loop) after initialization the WLAN module stops responding after some retries. If we delay the first call to wwd_wifi_get_rate() after the initialization (wwd_init()) the error occures faster! If we continue to use the 1ms delay for every SPI transaction even after intialization the IOCTL does not fail.
Some other users seem to have similar problems, but we have found no solution on the forum:
For now we added a delay of 1 ms for the first couple of SPI transfers which resolved the problem. However to gurantee a safe and stable operation we would really like to understand the cause of this behaviour.
We tried to rule out hardware based SPI problems.
We performed some tests driectly inside the wwd_bus_init function after reading the reset where the comment "/* Check feedbead can be read - i.e. the device is alive */" is located.
The Test–Read only register of the gSPI Interface returns always the same vaule when read in a loop.
Continously writing the Test-R/W register of the gSPI Interface with increasing numbers always returned the written number when reading.
Additionally we have sent 1200 byte UDP packets to an echo server and checked the returned packets for data inegrity using IP and UDP checksum. The test never returned an invalid checksum.