50g Random Turn ON

[3298]

(12-08-2016 11:04 PM)TravisE Wrote:  This is just a guess, but I wonder if the system somewhere maintains an internal, high-precision concept of what time it thinks it is, which gets periodically “refreshed” from a hardware clock (which might have a much lower timing resolution). Maybe the two tend to get out of sync at times for some reason until the system eventually updates one clock's time from the other, causing apparent jumps.

The Samsung S3C2410 (i.e. the 50g's brain) has an RTC, which might be what the Saturnator uses to keep track of time. After reading the relevant datasheet section I'm pretty sure (unless I misread it) that the most precise way of reading its value is the tick time interrupt (as the datasheet calls it), with a configurable period between 1/64 s and 1/2 s in steps of 1/128 s. Other than that, fractions of a second are not exposed to the software at all; the RTC register with the smallest unit is the one for seconds, which explains this CLKADJ weirdness:

(12-08-2016 11:04 PM)TravisE Wrote:  Another observation I've made before is that CLKADJ, when given a non-multiple-of-8192 increment, initially appears to work for a fraction of a second, but then something apparently “resets” the clock so that the effective adjustment resolution is only a multiple of 8192.

To me it seems like (though I'm just guessing here) the Saturnator tries to keep the 8192Hz counter up-to-date via software and constantly corrects it using the tick time interrupt. That would explain the "time travel" happening several times per second - the counter is corrected backwards. When the timer is written from within the Saturn world, the ARM system can only adjust the RTC by whole seconds, so it rounds the CLKADJ value to whole seconds (down? up? to nearest?), which causes the fraction-of-a-second part of the clock adjustment to get reverted on the next tick time interrupt.

So what does that mean for TIMER2? I don't know, my knowledge of the Saturn's interrupts is insufficient. But if it somehow depends on the 8192Hz counter working correctly (which I think it does, considering the talk here about a 31-bit counter and a 18-bit number of seconds), it might be broken. The 50G's displayed clock may still be unaffected even if one of the 3-day wakeups is missed if it's simply backed by the RTC which stays (somewhat) accurate.
My hypothesis for these random power-ups is that they are in fact caused by the 3-day wakeup, and if they are rarer than that, the calculator missed one due to clock jitter.

Perhaps someone should test for random power-ups on one of the pre-ARM calculators. Even better, test it together with an ARM-based one - turn both off at the same time and leave 'em for a week. The pre-ARM calculator should list two power-ups (3 and 6 days after turning off), and the ARM-based one should have up to two power-ups; if it has any, they should have occurred around the same times as the ones on the pre-ARM calculator.
Unfortunately I can't perform that test because my only pre-ARM HP calculator is a 48G that fell into water about 15 years ago. It didn't do much since, apart from convincing me to get my other HP calculator, a 50G.