Timers don't start on hard reset, but work fine after soft reset

[metri]

I have some code using timers. I create the timer, attach callback, then initialize the timer.
If I do a hard reset, the timers don't start. If I soft reset, they all start working. I can't figure out why they work on soft reset, but not on a hard reset. This is quite annoying as I have the pyBoard embedded in something. When it loses power, I have to connect to it and do a soft reset.

Any help would be very much appreciated

import micropython
import pyb

tick_timer = pyb.Timer(9)
ticks = 50

def tick(tick_timer):
global ticks
ticks = ticks + 1

# 10ms ticks
tick_timer.callback(tick)
tick_timer.init(freq=100)

while True:
print(ticks)

[ThomasChr]

Afaik are timers (like nearly everything else) not retained through a hard reset. Why should they?
A hard reset is like pulling the plug. Almost everything except flash content and (if a battery is attached) the RTC is gone then.

[metri]

Well, it's not about being retained. I thought my code would start the timers.

What I mean is, I connect power (Hard Reset) to the pyBoard, pyBoard executes boot.py

import pyb
pyb.usb_mode('VCP')
pyb.main('main.py')

Then proceeds to execute main.py. The code in main.py executes, except the timers don't run. The tick never increments, just stays stuck at 50. I know main loop is running as all other code runs. At this point if I do a soft reset, which effectively re-starts execution of main.py, the timers start working. I can't figure out why they don't work before I do a soft reset CTRL-D in REPL, but only after one.

[metri]

I solved the issue. In case it ever comes up for anyone else:

tick_timer.callback(tick)
tick_timer.init(freq=100)

Causes my issue, Timer does not run before doing a soft reset

tick_timer.init(freq=100)
tick_timer.callback(tick)

Works just fine. I guess callback is cleared after call to init()? Anyone have any idea on why this happens?

Clearly I ran things in the wrong order. The documentation clearly has examples with calling init(), then setting callback(). I just thought it seemed to make more sense to set callback, then start the timer.

[pythoncoder]

I can confirm that. I'm not sure if it can be considered a bug. The way I'd normally code this to set up the callback and the frequency in a single call to .init:

Code: Select all

import pyb
t = pyb.Timer(1)
def cb(_):
    print('rats')

t.init(freq=1, callback=cb)

[metri]

Thanks. I'm glad it wasn't just me. Is it a bug? I can't say it qualifies as a bug either. If init() is like the instantiator of a class, it should clear the callback. It is not documented to state init should be called first, but that alone shouldn't qualify it as a bug. I'm just happy it's solved and my code functions as intended.

Yeah I agree about calling it in one line. I can't say why I wrote it in two, simply came out that way

Thanks again

[jimmo]

If init() is like the instantiator of a class, it should clear the callback.

I agree the documentation could be clearer, but you are correct. The general design of all of these classes (and this has been carried into the "machine" module equivalents) is that init() is the same as completely reconstructing the object.

It is not documented to state init should be called first, but that alone shouldn't qualify it as a bug.

It's a bit subtle, but the documentation should really be saying that the callback kwarg to init() defaults to null. So your original code is effectively the same as:

Code: Select all

tick_timer.callback(tick)
tick_timer.init(freq=100, callback=None)

(Documentation are PRs most welcome if you have the time! )