As far as I can tell (I did not think to check these) these things
were working. Every display has a PtTimer on it. These all seemed
to restart themselves when the user switched away from, and then back
to, a page (thus re-realizing the widget). The display application
itself seems to remain working, except that anything that depends on
the main PtTimer (The one on the start-up page that is used for the
entire hierarchy) does not update. Other parts of Photon and the OS
seem to be working fine.
OK, then it’s not what I suspected it might be. That’s a good thing, in
When debugging the last occurence of this (on 4.25B, this occurence
was on 4.25G), we noticed that the display application seemed to go
into a RECV state and get stuck there. Whatever it was waiting for
never showed up. But the application still allowed us to switch
displays and use controls, but nothing updated that was based on the
main pttimer, and none of that widget’s callbacks were running
anymore. None of those callbacks would put the application in a RECV
It’s normal for most Photon applications to spend most of the time
RECEIVE-blocked on Photon. That’s how they wait for Photon to let them
know when something happens that requires their attention. If your app
still reacts to events such as mouse or keyboard input, it means that
it’s not stuck.
Is there any problem with having the startup display be a display that
is also frequently navigated back to from all the other displays
instead of a special startup display that has no other purpose than
running the PtTimer? Is there the possibility of more than one
instance of the main PtTimer occurring and causing a problem?
That may depend on what exactly you mean by “display” and “navigated”.
Is it a PhAB application? Are your “displays” separate window or dialog
modules that you “navigate” to and from by creating and destroying the
widgets? Or are they picture modules that you create and destroy inside
Normally, having multiple PtTimer widgets is not a problem. It’s not
recommended to have a lot of PtTimers set to very short intervals (under
20ms or so), because that causes Photon to re-arm its timer constantly,
which makes its timekeeping inaccurate. (It also increases the chance
of triggering the bug that, as it turns out, is not the problem in your
Are there any tricks to using the PtTimer? Any way to monitor and
force it to restart if it stops? I attempted to un-realize it and
rerealize it, but it didn’t seem to work.
No tricks should be necessary; since a PtTimer has no battery and no
moving parts and is immune to rust, it should keep running forever
If it does stop nevertheless, the trick is to figure out what the cause
is, and remove it.
A couple of things that might help:
#1 Do you ever set Pt_ARG_TIMER_INITIAL or Pt_ARG_TIMER_REPEAT from your
code after the widget has been realized, or is the widget supposed to
keep running with the values it was initialized with (e.g. in PhAB)? If
you do, does it happen inside of outside of the timer’s callback?
#2 Does your timer callback do anything that might cause it to get stuck
in a “modal” event-processing loop? Could you put a printf() at the
very top of the callback function, and another one just before its
return, to confirm that you’re not getting stuck inside the callback?
(A PtTimer does not keep ticking while in the callback – the code
receives a timer event from Photon, then calls your function, and then
asks Photon for another timer event. The repeat delay does not start
until after your callback has returned. If your callback never returns,
the delay never starts. There may be exceptions to this rule if you
re-realize the widget or set its resources without returning from the
callback; but hopefully, you’re not doing that, except to see what
happens if you do…)