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 timeouts to different IOCTL commands during wwd_wifi_stop_ap().
Our test case repeatedly starts a Wireless Access Point and closes it after some seconds again.
When a remote host connects to the Access Point and sends TCP data to the WLAN module before or at the time the AP gets stopped, sometimes the IOCTL commands during wwd_wifi_stop_ap() time out (wwd_sdpcm_send_iovar() returns with WWD_TIMEOUT).
The issue seems to be very dependent on the timing when the TCP packets arrive at the WLAN module.
For further investigation of the issue we adjusted the code of wwd_wifi_stop_ap() to repeat sending the IOCTLs if wwd_sdpcm_send_iovar() returned with WWD_TIMEOUT.
On the second attempt we then always receive the IOCTL response.
However before receiving the response of the second attempt the response of the first attempt (which timed out) is received from the WLAN module:
"Received a response for a different IOCTL - retry" (the id is 1 less than the value of wwd_sdpcm_requested_ioctl_id).
So it seems that the IOCTL response is stuck inside the WLAN module.
Increasing the WWD_IOCTL_TIMEOUT_MS from 400 ms to 5 seconds did not help to receive the IOCTL response.
Poking the WLAN module via wwd_bus_poke_wlan() did also not help.
Calling wwd_thread_receive_one_packet() repeatedly did not help either.
The timeouts occur with all 3 IOCTLs used inside wwd_wifi_stop_ap() with different rate:
- wwd_sdpcm_send_iovar() to query the bss state (often)
- wwd_sdpcm_send_iovar() to set BSS down (sometimes)
- wwd_management_set_event_handler() to unregister from apsta_events (very rare)
Are there any known issues that could result in the reply to an IOCTL being
"stuck" in the WLAN module?
Is there any other way to retrieve a stuck response other than sending the
IOCTL again? Repeating the whole IOCTL seems risky in some situations, because
the WLAN module might already have executed the previous IOCTL, therefore our
current workaround isn't an optimal solution.
on behalf of David Natwati