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 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

5 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


We are having the same issue with Murata Type 1LV module (CYW43012).

We are using WWD ported from Wiced SDK version 6.6.

Firmware and CLM blob for 43012 is also form Wiced SDK version 6.6 (WLAN Firmware    : wl0: Sep  5 2019 02:59:38 version (r722343) FWID 01-e0ff2d48)

Custom PCB with STM32H743

Communication with 1LV is done over SDIO

We have UDP and TCP server running.

UDP server sends ~1400 bytes every 70 ms to the client.

Client sends TCP packets of 5B with 1 s period.

Issue with WWD_NO_CREDITS appears randomly and more frequently with poorer RSSI.

No further communication with the WLAN module is possible until a power cycle is performed.

Also WWD driver does not handle this issue well, because wwd_bus_poke_wlan() does not help and after some time buffer for UDP TX packet allocation gets full and is not freed.

Our question is there a way to handle this situation without power cycle?

Level 1
Level 1
5 sign-ins First reply posted Welcome!


Were you ever able to resolve this? I am using the SN8200 module and am running into the same situation.

Seems like if enough traffic comes into the 43362 chip it gets in a fault state and stops talking to the stm32 chip.