Monitoring or troubleshooting lowpower sleep/deepsleep operations

I'm not asking about specifics of sleep yet, just more about how to more closely monitor what is actually going on.

I've built a little adruino sketch with my mkr1010 wifi (wired to battery), that largely sleeps except regularly reporting battery levels, or executing a bit more code if wake from interrupt.

Running straight off 3.7v lipo (without the sleep) the device runs powered for quite some time, without problems. After introducing a button that will simulate the ultimate end goal of waking on interrupt and calling LowPower.sleep or deep sleep, it looks like the device will sleep and never wake up, or never sleep. (based on some BUILTIN_LED stuff I send while "awake")

Seems like when I have the usb cable plugged in, sleep works differently... but thus far... USB serial logger has been the only way I've been able to trace.

My question is not so much how to fix the sleep problems as it is getting ideas about how I can more closely monitor what is happening, while not affecting the charging... and being able to deal with the deep sleep (when the device comes back online, windows doesn't always assign the exact same com port, so the serial monitor doesn't just reconnect).

Should I just set up a simple local MQTT server and watch messages I post there while in a "debug" mode? Or is there something far simpler I am just somehow missing?

Appreciate any tips. I am surely going to still need to find out what / why things are going wrogn with sleep, but I feel like if I can see exactly what is happening, I can probably do some more relative google searching etc.

Thanks again!

Welcome to the forum!

ronnyek:
Seems like when I have the usb cable plugged in, sleep works differently...

Because the device uses native USB, the device will still need to handle the USB stack. It likely gets regular interrupts.

ronnyek:
..as it is getting ideas about how I can more closely monitor what is happening, while not affecting the charging... and being able to deal with the deep sleep (when the device comes back online, windows doesn't always assign the exact same com port, so the serial monitor doesn't just reconnect).

You could use a second Arduino as a USB-to-Serial bridge. Connect your Arduinos Serial to the "bridge" and use regular printf debugging. The regular port should be Serial1 instead of Serial. Because the "bridge" would stay connected all the time the COM port will not change.

ronnyek:
Should I just set up a simple local MQTT server and watch messages I post there while in a "debug" mode? Or is there something far simpler I am just somehow missing?

This is likely a bit of an overkill for simple stuff but with MQTT you can send your data to all kinds of tools. I have used MQTT and Node-RED for some experiments running over days until the battery died. It is better than reading trough log files. I stored the data in influxdb and used the query language to search for max, min values ... or displayed the graphs of values changing over time.

For shorter time analysis you could get yourself a logic analyzer and use I/O pins for debug. Have a look at PulseView. It is open source and works with Logic Analyzers for around ~$10 or Euro. Search for 24MHz 8 channel Logic Analyzer.

https://sigrok.org/wiki/Downloads

It has decoders build in, so you can decode all kinds of protocols e.g., UART, SPI, I2C, CAN ...

First of all, thank you very much for the response.

I hadn't thought about that, and didnt realize mkr1010wifi had two serial lines. What about just getting a simple usb to serial breakout board, and hookign that up to serial1, and then connecting both usb devices, and constantly monitoring the com port for the second usb.

(This might be exactly what you described, just using an arduino)

Seems like this would allow me to continue to push code to the mkr board, as well as constantly monitor second serial. Then I'd just need to make sure to write that debugging/tracing code to serial1.

I'll have to do some research into how adding logic analyzer stuff... it seems interesting and definitely advantageous. Is that something that would also allow for debugging in arduino advanced IDE (someone said the mkr1010 series was missing componetns on the board to hit breakpoints etc, but made it sound like it could be added.)

ronnyek:
What about just getting a simple usb to serial breakout board

How much cheaper than an Arduino Nano 33 IoT is that? That is the little variant of your board without the battery electronics. That can be useful for other experiments e.g., two Bluetooth or WiFi devices talking to each other.

https://store.arduino.cc/arduino-nano-33-iot

ronnyek:
I'll have to do some research into how adding logic analyzer stuff...

You can simply toggle a couple of pins for instance to measure time intervals, listen to communications between the Arduino and sensors and a lot more. If you download the software it comes with some example traces. You can play without hardware.

ronnyek:
Is that something that would also allow for debugging in arduino advanced IDE (someone said the mkr1010 series was missing componetns on the board to hit breakpoints etc, but made it sound like it could be added.)

For that you need an ARM Cortex-M debug adapter. But I am not sure which one works with the Arduino Pro IDE.
The MKR1010 schematic from the store shows a pad called J2 with 6 pins. I suspect they are the six pads under the MKR PCB next to the 1010 print. I do not have one and only looked at the picture in the store. I use the Nano 33 IoT. That pad is connected to 2 Serial Wire Debug (SWD) pins. These are available on all ARM Cortex-M based microcontrollers.
You could connect every Cortex-M debug adapter and use a supporting IDE e.g., ARM/Keil, IAR, Segger, Lauterbach .... But the point of Arduino is to do high level printf debugging for simple sketches. For products with volumes, you can always create a prototype board with proper debugging and all the application specific electronic you need.

https://store.arduino.cc/arduino-mkr-wifi-1010

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.