We noticed in our module (BC660K) a software reset that we could not find the cause.
So far, what we suspect is the
Ql_Timer_*() API that is causing the software reset.
Our firmware (in summary) connects to a remote server via UDP, and implements a “PINGREQ” mechanism to a remote server, where the server then replies like a “PINGACK” (similar to a keepalive in MQTT).
This PING mechanism uses a registered timer via
Ql_Timer_Start(), where the autorepeat flag is set to true. So this timer runs forever with an interval of 30 seconds.
Besides that, we also have another timer, that runs every 60 seconds repeatedly, where it checks the signal quality (AT+CSQ).
Both timers belong to the same task.
Since debugging is a bit hard for this reset problem, any help is welcome since we could not figure out yet what is the core cause of the software reset.
You can call RIL and then query the CSQ by AT Command
Hello @herbert.pan-Q ,
Sorry, I didn’t quite understand your answer.
Just to make myself more clear, I am suspecting that the software reset is happening due to the overlapping of the two timers (at some point, they will overlap, because the first is running at 15 seconds, and the latter at 60 seconds). Rather than that, I do not see what could be causing this.
But, as I mention, this problem is very hard to debug, so, any idea on how to debug such corner cases would be welcome.
Unfortunately, the software reset is happening at very random times. During my tests, it happens at 20 seconds after boot, sometimes at 10 minutes, 15 minutes, etc… Non-deterministic.
We identified the problem using EPAT tool.
Our task stack was too small, and the EPAT reported a stack overflow on the task.
Has the problem been solved?
Yes, increasing the stack size of the task solved the issue.
No software reset was seen anymore.