DeviceOS5.3 running on an Argon
Call to WiFi.clearCredentials(); is causing an exception 13 red flashes
Same firmware on a P2 works.
Is WiFi off, on, connecting or ready at time of execution?
I guess the best time to clear credentials would be with the module on but not connected.
However, having it crash under any circumstance is no good.
WiFi would be on, as we have just scanned for WiFi networks as part of our BLE based credentials setting app, we normaly do a clear before doing a set.
I tried it there turning WiFi off first and the same happens.
Works on DeviceOS5.2 on the Argon.
1 Like
Can you please confirm whether panic 13 (stack overflow) happens when you run WiFi.clearCredentials() from setup() or loop()?
It is being called from the reception of a BLE command in the onDataReceived function.
So not in setup()
BLE event thread (where the onDataReceived callback is being executed from) has a limited amount of stack: 2KB only. Heavy calls such as WiFi.clearCredentials() should be moved to application or some other worker thread with larger stack size, otherwise yes, it is very easy to run into a ‘stack overflow’ situation. We could potentially increase it but that is sacrificing total amount of RAM available to the application, we can easily do this on P2/Photon2, but probably not for nRF52840.
The fact that this successfully worked on 5.2.0 is to some extent ‘by chance’. Variations in internal implementation of clearCredentials(), compiler optimizations, BLE HAL implementation and other things happening in the callback can all affect stack usage, and these heavy APIs like WiFi.clearCredentials() are not guaranteed to work.
Moreover executing heavy and time-consuming things (clearCredentials() being one as that operates with the QSPI flash/filesystem) should be discouraged, as that is blocking processing of other BLE events.
4 Likes
Moved the clearCredentials() out to the main thread and that fixed the issue.
Thanks for the advice.
Gary