Open youca04 opened 1 year ago
Hi,
Could you share the wfx driver and firmware version used? It would also be helpful to know more about the ecosystem the driver is running in (RTOS, IP stack...).
Hi,
Thanks for responding so quickly. Here is a summary of the details to the best of my knowledge (I'm not totally up to date with the WFX architecture or this product - just been asked to assist to find a fix to this issue).
WFX firmware image: 3.14.0 Driver? FMAC_DRIVER_VERSION_XXX: 3.2.2 LWIP: 2.1.3 FreeRTOS tskKERNEL_VERSION_NUMBER "V10.2.0"
The WF200C is being driven by SPI at 500K. The host processor is an NXP i.MXRT1062. All other Wi-Fi functionality appears to be fine - only querying for signal strength causes intermittent faults. There is plenty of free heap space, and the related tasks all have significant free stack space.
I left my dev device running yesterday - querying for status twice a second, from about 15:13 to 18:00 - and there 26 crashes recorded in the log files over that time frame. Not a huge amount in the time frame, but enough.
Some of our production devices are faulting every 30 - 60 seconds or so,
Thanks,
Carl
Hi,
I was querying for the RSSI value as you did. The tests were run for around 90 mins at each 2Hz and 4Hz querying rate, and the firmware replied without faults. The measured RSSI is around -45~-50 dBm
My settings are as below: FreeRTOS v9.0.0 WFx Firmware v3.13.0 WFx driver v3.4.0 LWIP 2.1.1
Can you tell us what other activities does your wf200 module had to do at the same time? Things like ping, sending files, etc.; and does the problem persist if other activities are disabled, which means that only sl_wfx_get_signal_strength() is called at the mentioned frequency?
Best regards, Dzung.
Hi Dzung,
Thank you for your tests. The module was not doing anything in particular when the crash occurred, but I haven't added any detailed logging yet to check exactly what may be happening.
I will try a test where I add mutual exclusion for all tasks with this API to see if it helps. I will also add some additional profiling code to trace the task states.
Regards, Carl
Hi,
I am revisiting this issue that my colleague reported a few years back. We are using newer firmware and someone tried to 'fix' the code to correctly read sl_wfx_get_signal_strength() rather than the spoof readings that were added to stop a crash.
This is on a WF200C connected by SPI. We see a firmware exception - reason 4 - from the SL_WFX_EXCEPTION_IND_ID event, with the following trace code.
I'm hoping some can advise us on what to look for. It feels like a concurrency locking issue to me as I only see it on some machines intermittently but see it more often now I have increased the calling frequency to about 4 calls per second.
Thanks, Carl