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 IOCTL timeouts after WLC_E_LINK and WLC_E_DEAUTH_IND events for some seconds.
We use two devices for this test.
One device (called "AP") repeatedly starts a wireless access point on a random channel, keeps it open for some seconds and closes the AP after some seconds.
The other device (called "STA") tries to connect to the access point and on link loss it always tries to reconnect to the AP.
On a successful connection, our application registers for the WLC_E_LINK and WLC_E_DEAUTH_IND events.
Usually the WWD driver receives the link loss event from the WLAN module when the AP stops and switches to a different channel.
Our code then calls wwd_management_set_event_handler() to unregister from the WLC_E_LINK and WLC_E_DEAUTH_IND events and then wwd_wifi_leave() to disassociate from the AP.
This procedure works in most cases without problems.
If we send lots of UDP datagrams from "AP" to "STA" during the time the access point is started, in rare cases the WLAN module does not respond (WWD_TIMEOUT) to the IOCTLs while handling the LINK_LOSS event.
wwd_management_set_event_handler() and wwd_wifi_leave() both return WWD_TIMEOUT.
Further communication with the WLAN module is possible after some time.
When trying to reconnect to the AP after wwd_wifi_leave() returned with WWD_TIMEOUT (by repeating wwd_wifi_join() until success), the WLAN module sometimes does still not respond to the IOCTLs in wwd_wifi_join() for up to 3-5 seconds (or up to 6 IOCTLs).
After some time the WLAN module starts responding again and returns all "previous" IOCTL responses (wwd_sdpcm_process_rx_packet() reports "Received a response for a different IOCTL - retry" up to 6 times!).
The WLAN module then successfully connnects to the AP again.
How should an application handle link loss events received from the WLAN module?
Are there other events that we could wait for that indicate that the WLAN module
is ready to handle a new connection attempt?
Is our approach of registering the events WLC_E_LINK and WLC_E_DEAUTH_IND for
application purposes ok? Is it ok to unregister these events after one of the
events triggered? Is it ok to call wwd_wifi_leave() afterwards?
More generally speaking:
Are there any known issues that could result in the
WLAN module not responding to IOCTLs for several seconds?
Are there any known issues that could result in multiple replies to IOCTLs being
"stuck" in the WLAN module?
Is there any other way to retrieve a stuck response?
on behalf of David Natwati