Testing millis() overflow

#1

Hello,
The RTC uses the millis() counter to keep time as shown below. This code is defined in Time.cpp

image
image.png973×386 31 KB

Since the millis() counter runs even during sleep( and I want it to run because I am using the RTC to wake), it will overflow after about 50 days. I want my device to last for a few years.

Now if the framework is implemented properly, then the code above would still work after a millis() overflow as laid out bye Nick Gammon here.

Even so, I want to test it by assigning a large value to the millis counter(). On regular Arduino’s I use an atomic block.
image

But the Heltech cubecell does not support this. Is there a way for me to test the millis() counter overflow?
Thanks =D

1 Like
#2

Hi,

did you find any solution to this? Would be interested to try something similar but I don’t want to wait for 50 days ^^

#3

millis() return a 32bit unsigned data. I think you can set some paras check if it is overflowed :

set two global paras:
uint32_t lastmillis = 0;
uint32_t overflowtimes = 0;

when you want to use millis(), do like this:

uint32_t temp = millis();
if(temp < lastmillis )
{
overflowtimes ++;
}
lastmillis = temp;
uint64_t millis_64 = overflowtimes * 0x100000000 + temp;

1 Like
#4

Surprised you never got squiggles for the timer0_mills=0 . This must only be ok with Arduino environment with esp32. Even so you would need to disable interrupts and then enable them again after timer0_millis=ms . I am looking for a solution to reset millis() before sleeping on a cubcell module. Because I need to rule out a possible millis() rollover while asleep, that prevents a wake up issue i seem to be having.

#5

How would a millis() rollover trigger an (unexpected) wake-up event in your App?

#6

I could deal with an unexpected wake up event. But it’s hard to know whats going on when the cubcell fails to wake after a normal routine of waking up. Sort of died in it’s sleep. However from calculating that it’s about 29 days for a roll over to occur. My devices seem to fail to wake up after 2 to 3 days. So there is another problem i have not discovered yet.They are on solar and battery. I have them waking up every 6 hours to report their voltage. As my suspicions are looking at brown outs when trying to wake from sleep. With overcast weather at the moment. They are consistently hovering at 3.61v with a 0.2v increase over 24hours. What i want to test is at what what voltage did i last hear from them. And then leave them to see if they ever recover in better charging state. Or ones they drop below a certain voltage. They loop into a constant instant wake/reset state drawing more current than the solar panel can overcome to keep the cubcell from brownout loops.

#7

Sleep is really ‘deep sleep’ taking < 10 uA?
When you restart a device after it failed to wake up after 2-3 days, does again work for 2-3 days?

(In other words: battery capacity is fine after 2-3 days and still sufficient to deliver peak power during radio transmissions?)

#8

The problem of not waking up has gone away. Seems with my new code checking the voltage on wake and if less 3.65v quickly send voltage data and switch lora radio off. to save power and also not wake on radio receive interrupt for low low power . And then quickly sleep for 6hrs. if Greater than 3.65v then wake for 6 seconds sleep for 6 minutes with lora radio on . This wakes up the cubcell when it receives a packet.If it is a send your data request form the base lora esp32 device connected via wifi to Thingspeak, then it sends it with device ID. with HOP position for packet forwarding.Here is the voltage graph of 4 of the cubcells .https://thingspeak.mathworks.com/channels/1838276

#9

Problem solved? (Sorry, I didn’t understand everything you wrote.)

#10

Yes problem solved. Thank you

#11

I have published my Lora_mash project here GitHub - Andy1968T/Cubcel-Heltec-Mesh-Lora · GitHub