I have an application that periodically wakes up, communicates with an external device via UART2, uploads some data via FTP, and then goes back to low power mode. This code runs fine on the old Q26 Extreme.
I’ve been trying to migrate to the Q2698, so I built a new project and imported all of the code. What I’m seeing is that the application randomly and inexplicably resets a couple of times each day. There are no backtraces - it just resets.
Has anyone else encountered this sort of problem with the Q2698, or better yet found a workaround for it?
Can you trap the reason for the reset/power cycle? Have a look at the adl_InitType_e and adl_InitGetType() documentation in the API. It’s a bit rough - but at least you’ll know if its an exception or external power issues that’s causing the restarts.
You might have to add lots of traces to your Application and then leave a PC logging them to see if you can get any more. If it’s an exception that is causing the reboot, you should be able to get some info out of the device as it happens - IF you’ve got a pc logging it at the time.
That would suggest that there is some sort of power glitch happening … as a watchdog timeout or memory buffer overrun will give you a ADL_REBOOT_FROM_EXCEPTION issue. However, issuing a AT+CFUN=1 will reboot the modem and the restart type will be ADL_INIT_POWER_ON.
Are you switching power modes (i.e. using the 32kHz clock to reduce power consumption) in your code? I’ve never done this, but I’m wondering if this is forcing a power reset.
Can you shorten the sleep period (i.e. wake up more often) and see if that trips this problem?
Finally, check to see you’re not getting spurious noise on the RESET pin of Q2698 that’s causing the module to reset? Have a close look at the PTS and see what it says about using the reset pin.
If there’s a power glitch I assume it’s with the Q2698 itself as I’ve tested it on a custom PCB and the Q26 Dev Board that have both worked flawlessly with the old Q26 Extreme. My code isn’t issuing it AT+CFUN=1 restart commands.
I do use the 32kHz clock, but I have it dropping in and out of this mode every five minutes. In a day that’s 288 wake ups, yet the problem only occurs for a handful of these (i.e. I can’t forcibly reproduce it).
I’ll need to systematically comment out parts of the code to see if I can determine which part of it is related to the random resets.
This random restart reporting a ADL_POWER_ON event has reminded me of something I struck 18 months ago.
I had a modem that was uploading data to a server using the WIP FTP API. Occasionally I would get both REBOOT_FROM_EXCEPTION and POWER_ON restart events - I eventually tracked down the REBOOT_FROM_EXCEPTION to a buffer overflow problem, and the POWER_ON event appeared to occur when I was within the WIP FTP API.
I never did resolve the FTP issue - it appeared that the module was somehow being power cycled from within the FTP library under certain conditions. Like yourself, I was not getting any debug traces out when this happened, and in the end I talked the client into using HTTP to do the uploads instead of FTP - and the problem went away. I was also logging data (at roughly 5 sec intervals) internally to the A&D flash and there was a gap of about 30-40 minutes between the last logged record and the POWER_ON event. This lead me to believe that there is a long timeout somewhere in the FTP or TCP stack that was hanging up on me - but I have no proof.
I was running my code on a Fastrack FXT009 with FW 7.45 and 7.46 (and associated WIP libs etc).
If you’re convinced that there is no real power problem (and from what you’ve said I now believe that there isn’t), the next place I would start looking is inside your network code (if you’re using TCP) and see if you can do some internal logging yourself - even just dumping internal state variables out the USB or serial port to a PC would be useful. The TCP library has some very long default timeouts that can be tweaked using the wip_netInit() options - maybe shorten these timeouts and see how the problem behaves.
The WIP FTP library is certainly very finicky. It took me a lot of effort to get it working consistently, and even then it will sometimes just decide not to generate an event after wip_bearerStart().
That said, I commented out all the FTP stuff and ran it overnight and it’s still resetting. That leaves me with the 32kHz mode or the UART2 comms. I’m still hoping that I can track it down to some particular operations.
Nope, I disabled the 32kHz mode and it still does it. It doesn’t seem to matter what I enable or disable, it always randomly resets within a couple of days!
Depending on which firmware version you have, you might get some backtrace info out of the module after it’s rebooted using DevStudio. It’s not as good as real-time traces, but might at least help narrow which module or library is exploding on you.
There’s a thought - can you back/forward port your code to different versions of firmware (and libraries)? Might at least help SiWi track down where it’s happening.
It’s odd that you’re getting a “Power On” rather than that “Reboot from Exception”. Might be time to tap your distributor on the shoulder and get them to raise a ticket with SiWi.
Yeah, one of the first things I checked for were back-traces. Alas, there was nothing!
My distributor has opened a ticket with SiWi so hopefully something comes of it. Otherwise I might just have to start writing to non-volatile memory a lot, but I don’t want to burn out the flash.
That’s not good.