ticks_ms() return big value at startup with custom firmware

[thibault]

Hello, i have try to use the frozen way for try. I have get a fine tar.gz image for flash a lopy. All seems fine, but there is a strange behaviour about the uptime() function of my module. my uptime function require ticks_ms() from utime for run fine. On the official firmware this run fine without problem (it is normal that when we use the machine.reset() function the utime() return was not reset?).

But when i use the firmware from compilation (pycom-micropython-sigfox) ticks_ms() seems not be initialized at startup. It's not a problem for me, but i think it is not normal?

Anybody have a same behaviour?

Thank's for answer, and have a nice day.

P.S.: os.uname()
(sysname='LoPy', nodename='LoPy', release='1.20.2.r4', version='v1.20.1.r2-364-g915d42cca-dirty on 2021-03-10', machine='LoPy with ESP32', lorawan='1.0.2')

[robert-hh]

@thibault Which branch do you use for building? And what is the values that you get first?

[thibault]

@robert-hh i have follow the README.md of pycom-micropython-sigfox and i have use the branch pycomidf_v3.3.1 for pycom-esp-idf and the Dev branch for the pycom-micropython-sigfox.

And at the startup of the device i get from ticks_ms() approx 1791996536 wich means 20 days 17 hours and 47 minutes..

After i set the right clock value with rtc.init() the ticks_ms() return a more recent value with 546422236 wich mean 6 days 7 hours 46 minutes.

Do you think that a such behaviour come from the Dev branch? Maybe it's not a good idea to use this dev branch? Do you have a suggestion for a better branch?

Thank's

[robert-hh]

@thibault I'm using the Dev branch too, and have not such huge values. This value is also not special by any means.
ticks_ms() calls the espressif lib function gettimeofday(), which reads the RTC registers. So it's the RTC not being reset or set to strange value.

[thibault]

@robert-hh thank's for the information. That trouble really. I have try the same firmware on two device and i get the same behaviour with nearly same value.

On your firmware, you get right a value near 0 at startup for ticks_ms()?

[robert-hh]

@thibault If I add print(time.ticks_ms()) to main.py, I get values of ~1700. So that's fine and the boot time up to that point. Do you get these values too when you push reset?

[thibault]

@robert-hh i think you have find that this behaviour come from my code.

When i add this print(time.ticks_ms()) in the main.py, i have get this value: 179199555

But i have see that my frozen code was launch before the new main.py. So i have write this print in the boot.py and now i get this value: 1337

And this remember me that i have a code wich set a default date at 1/1/2000... so i think this is was link to my strange behaviour of ticks_ms().

@robert-hh thank's you for helping me understand this behavior. I thought this ticks_ms function could be used as an alias for the uptime command, and that it is just a counter initialized at system startup, but obviously it is not! :) Have a great day!

[kjm]

@robert-hh I'm surprised that time.ticks_ms() uses rtc registers Rob. I use time.ticks_ms() to track program flow rather than time.time() precisely because the former is unaffected when the rtc resyncs.

[robert-hh]

@kjm It uses gettimeofday(). I understood from the espressif docs that this function gets its values from the RTC registers. But it may indeed be different.

[kjm]

@robert-hh said in ticks_ms() return big value at startup with custom firmware:

gettimeofday()

Which brings me to my other question of do you know why gettimeofday() isn't available in userland?