We are using a murata SN8000 module connected via SDIO operating with 48 Mhz 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, MCU and SN8000.
The MCU is operating at 180 MHz.
We are using an older version of FreeRTOS and LWIP (not taken from the SDK).
The SDIO interrupt has the highest interrupt priority.
The WWD task has the highest task priority.
There should be no long interrupt processing during the test.
During synthetic tests we experience reproducible cases when the WLAN module stops accepting SDPCM bus data.
Our test case connects to a WLAN access point and performs several TCP communication scenarios (repeatedly connect to a remote host, transfer many data to remote host, etc) for about 30 minutes.
For a last test step the remote host is configured to drop all incoming network data. The last test step tries 100 times to establish a TCP connection to the remote host with a timeout of 1 second each, which are intended to fail (timeout after 1 second) because the remote host drops all TCP SYN segments.
Afterwards the "drop all incoming network data" is disabled on the remote host and our code performs a TCP connect to the remote host.
Usually this test case performs successfully. However in about 1 out of 10 test runs, the WLAN module stops sending data to the remote host in the middle of the 100 TCP connect loops. We can see the TCP SYN segments every second until suddenly (varying, after 50-90 seconds) the module stops sending them.
Further analysis shows that the WWD driver runs out of bus data credits.
wwd_sdpcm_get_packet_to_send() keeps returning WWD_NO_CREDITS forever.
It seems that the WLAN module does not give the WWD thread bus data credits when the thread calls wwd_bus_poke_wlan(), however wwd_bus_poke_wlan() always returns with WWD_SUCCESS.
This results in the SDPCM packets (in the send queue) never being transferred to the WLAN module.
No further communication with the WLAN module is possible until a power cycle is performed.
If we only perform the last test step (with the 100 TCP connection attempts) repeatedly, the issue does not occur.
If we endlessly loop sending TCP SYNs (that are all dropped by the remote host) the issue does also not occur.
Are there any known issues that could result in running out of bus data credits
and not getting any bus data credits anymore?
How are bus data credits implemented on the WLAN module, and what events should
cause the WLAN module to give more bus data credits to the WWD driver?
Is there any other way to bring the WLAN module to a state where it responds
again other than performing a power cycle?
Best Regards,
Michael Liebert
on behalf of David Natwati
