Exactly.From the behaviour you describe, isn't it simply that whenever POWMAN_TIMER_RUN gets set, the count is loaded from whatever is in the POWMAN_SET_TIME_xxx registers?However, I figured out a workaround. On bootup I test the value of POWMAN_TIMER_RUN, and if it is set to 0x1 I don't touch POWMAN_TIMER or any other AON Time-related registers; in that case the time of the AON Timer is not reset to the time that I had previously written to POWMAN_SET_TIME_*.
So setting POWMAN_TIMER_RUN only if it isn't already set is not so much a workaround, as required operating procedure when you want continuous timing. No?
Yes. On power cycling POWMAN_TIMER_RUN Is set to 0x0.(BTW, if you're finding POWMAN_TIMER_RUN already set, it means the 'reboot' we're talking about is software-initiated, right? )
Agreed completely ─ while this issue isn't bad enough to require changing (even though RPi Ltd might as well change it if they are going to do a future respin anyways), as there is an easy way to work around it, it should at least be documented.Indeed, the description of POWMAN_TIMER_RUN does *not* suggest the behaviour I describe. if I'm right then it should certainly be better documented.I saw nothing in the reference manual that indicated that setting POWMAN_TUNER_RUN or any of these other fields resets POWMAN_READ_TIME_UPPER and POWMAN_READ_TIME_LOWER to the original time written into the lower 16 bits of POWMAN_SET_TIME_63TO48, POWMAN_SET_TIME_47TO32, POWMAN_SET_TIME_31TO16, and POWMAN_SET_TIME_15TO0 (i.e. ignoring the $5AFE written into the upper 16 bits thereof).
Statistics: Posted by tabemann — Mon Sep 02, 2024 7:01 pm