CLM blob download failure when doing late wiced_wlan_connectivity_init()

[user_108962310]

I am having an issue with WWD initialization by using wiced_core_init() separately from wiced_wlan_connectivity_init() .
I am getting a return of TIMEOUT from wiced_wlan_connectivity_init(), and the associated output message saying that the CLM download has failed.

In my system, I would like to delay the WLAN init since it takes 1-2 second. Right on startup, I want to do wiced_core_init, then show the animation, then do wlan init after it is finished.

For the animation, I am using a worker thread that is running at high priority, priority 2. I have also tried it at all other priorities, but the failure remains.

Interestingly, removing the animation and replacing it with an rtos delay (in the app thread) does alleviate the issue.

Also interestingly, this ONLY happens in a release build, and using a -debug build, the late call to wiced_wlan_connectivity_init will give successful wlan init.

From tracing the target, I can see that the failure happens in wwd_sdpcm_send_ioctl(), on the line where `wwd_sdpcm_ioctl_sleep` is taken:retval = `host_rtos_get_semaphore( &wwd_sdpcm_ioctl_sleep, (uint32_t) WWD_IOCTL_TIMEOUT_MS, WICED_FALSE );`

The CLM blob resource size is being fetched from external sflash from a WICEDFS section, and the size is being reported correctly (7222 B).

I am using SDK 6.1.0 (thus wifi FW + CLM blob in WICEDFS), and notably this whole phenomenon does NOT happen for nearly identical code in SDK 5.1.0, where the monolithic wifi_fw + clm_blob are being loaded from the WIFI_FW section of the sflash. In both cases, an STM32F412 micro is used.

Any insight into how to make this work? Of course, I need to use a release build when it comes time to ship, and it would be great to not have to include the 2-second wait right at device power-up.

[PriyaM_16]

Can I know the time taken in showing animation?

[user_108962310]

Total animation time is 4500ms.

I tried a minimum working example test that ONLY did separate wiced_core_init() and wlan init with an rtos delay inbetween, but I did not find a decisive number past which the setup would time out. Most times above 6500ms would not work.

I also tried deferring the wlan init to a worker thread or even a dedicated thread so it would be backgrounded or interleaved with the animation, where the animation is implemented a finite state machine that re-enters itself with timed events, and lived in a worker thread dedicated to the display.

[PriyaM_16]

Hello Andrew,

The problem seems to be in acquiring the semaphore when the wwd_sdpcm_send_ioctl() is called(which you already pointed out).

I tried to find the reson for clm download error and it returns error because of timeout.

If the time for acquring the semaphore in wwd_sdpcm_send_ioctl() at

/* Wait till response has been received  */

   retval = host_rtos_get_semaphore( &wwd_sdpcm_ioctl_sleep, (uint32_t) WWD_IOCTL_TIMEOUT_MS, WICED_FALSE );

is increased, the issue will be resolved.

The timeout should be more than the delay you wish to keep between wiced_core_init() and wiced_wlan_connectivity_init(). By default the timeout is 5000 ms(WWD_IOCTL_TIMEOUT_MS).

[user_108962310]

Unfortunately, that does not solve the issue. Even when setting the timeout to a very high value, e.g. 15000 ms, the system will pend there for the full 15s and then fail. It seems that one of the reply messages is getting missed, or whatever is meant to send it is never getting sent.

To try to debug this, I added this right before the semaphore get in wwd_sdpcm.c, as I was attempting to check at what time each item was being run:

{

    wiced_time_t now;

    wiced_time_get_time(&now);

    WPRINT_APP_INFO(("get sem on wwd_sdpcm_ioctl_sleep at %lu\n", now));

}

Adding that print statement actually causes the startup sequence to apparently work in the release build: no CLM load error, and the startup order is all interleaved correctly.

But then, upon connecting to wifi, there is an unhandled interrupt in wwd_wifi_register_multicast_address_for_interface , in _nx_packet_release.

In the debug build, that exception is not hit.

[PriyaM_16]

I faced similar behavior but if the delay between wiced_core_init() and wiced_wlan_connectivity_init() is increased, the clm error still appears.

Increasing the timeout for acquiring wwd_sdpcm_ioctl_sleep helped in removing the error.
About the wifi connection, I will need some more information to recreate the exception. I tried to bring up network and it appears fine.

[AxLi_1746341]

riya wrote:

I faced similar behavior but if the delay between wiced_core_init() and wiced_wlan_connectivity_init() is increased, the clm error still appears.

Increasing the timeout for acquiring wwd_sdpcm_ioctl_sleep helped in removing the error.

The default WWD_IOCTL_TIMEOUT_MS is 5000 ms which is pretty long.

If such long timeout is still not enough, you should think about *why*.

The most common issue of your workaround is: it may work for some devices but still hit issue on other devices.

Don't increase the timeout unless you really understand what you are doing. Otherwise, you are just hiding bugs.

[user_108962310]

A follow-up to this issue: per another recommendation, I added a delay of 1 second before:

result = ( wiced_result_t )wwd_management_wifi_on( country_code );

in file WICED\internal\wifi.c .

That change appears to help things. I still occasionally get failures, but much less frequently.

However, I def agree that there is something else wrong here, and there is some kind of edge case or lack of safe or robust startup sequence for the radio and/or WWD and/or WAF in SDK 6.1 . It is *very* low level, so it's damn hard for an SDK user like myself with limited knowledge of how the WWD is implemented to debug.
It would likely only take 1 or 2 days to fix for someone who is familiar with the WWD, and who has a dev board with ETM trace and a logic analyzer on the SDIO bus.

Alternately: is there a way to speed up wlan startup without having to defer it until after other system startup?

[PriyaM_16]

I will try to find the reason for this error(The "why" part) and see the time dependency between the two function calls. The error seems to be random and its hard to make a test case where it definitely fails.

[PriyaM_16]

Hello Andrew,

Can you upgrade to latest SDK and report back if you still observe the error?

I tried in the latest SDK and there is no problem in initialization.