Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable

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?

Best Regards,

Michael Liebert

on behalf of David Natwati

13 Replies
250 sign-ins 25 comments on blog 10 comments on blog

Moving to the Murata forum, adding the Murata technical team:


Not applicable

This appears to be a WICED firmware question, not a Murata hardware issue.


Per Ryan, moving back to the WICED Wi-Fi forum, adding the technical team: gangi​, seyhanvik86


Is there any follow up for this issue that can be released to public?

I'm facing similar issues that <wwd_management_set_event_handler> never returns when trying to disconnect from AP.


Adding the level 1 AE team so they can review and escalate to L2/L3 engineering as required.



Hi mifo​ & Cypress team
Is there any update?

10 questions asked 250 solutions authored 250 sign-ins

Please use the current version of WICED 5.0. The link loss events have already been handled in the callback function wiced_link_events_handler() that is registered by wwd_management_set_event_handler( link_events, wiced_link_events_handler, NULL, WWD_STA_INTERFACE ); in the function wiced_join_ap_specific() in wifi.c. You can check the function wiced_link_events_handler() to see how the events WLC_E_LINK and WLC_E_DEAUTH_IND have been handled. You will find a function call link_down(). In this function, the network stack is notified that the link is down and the networking worker thread is forced awake.

The wiced_link_events_handler/link_up/link_down things are there since sdk-3.x.

Does sdk-5.0 have bug fix in this part? (Changelog does not mention this)


I don't see any difference in the implementations of the handlers in WICED 3.7.0 and WICED 5.0. Moreover this has not been mentioned in Changelog which means that this issue has not been addressed.

xavier@candyhouse​ can you elaborate your issue on wwd_management_set_event_handler never returning? I will also try to reproduce the issue under the conditions mentioned in the first post.

Working with SDK 4.0.1

The symptom is "<1% chance wiced_leave_ap never returns when we want to disconnect from WIFI AP".

Unfortunately we see this on our app which is not easily simplified to a piece of snippet.

Our app tries to be always connected to MQTT broker, and the key actions are:

1. connect to wifi ap

2. connect to MQTT broker with root_ca, key and certificate. keep_alive = 10

3. (app logic) publish / receive MQTT messages, do BLE operations


5. If it fails to reconnect to MQTT broker immediately, disconnect from wifi ap and start from 1.

The above executed continuously for days and experienced hundreds of MQTT / wifi ap reconnection.

And one day it hanged forever, and the last UART output showed that <wwd_management_set_event_handler> inside <wiked_leave_ap> (or <wwd_wifi_leave>, sorry I don't clearly remember) was called but it never returned.


How is the status? Do you get any fix?




We simply stop investing more resource in this chip and start our next with other platform.

Basically we end up with watchdog workaround and disappoint ourselves with a "non-always-online product".

Good luck.