External RTC logic sets hour to "19" on boot; everything else works

[dansanderson]

Test Environment (required)

• Platform: MEGA65
• Core Commit: f555316 (198)
• ROM Release: 920371

Describe the bug Using an external Real-Time Clock (RTC) sets the hour to "19" on boot. All other features appear to work: the year, month, day, minute, and second values can be set in Configuration, and advance correctly with both power on and power off.

I have a batch #1 MEGA65 with a faulty internal Real-Time Clock (RTC) that does not tick. I acquired a DS3231 RTC in a package intended for RaspPi applications, along with a Grove connector cable, and installed it according to published instructions. The battery of the DS3231 external RTC had low voltage (0.8V) so I replaced it with a CR2032 (2.6V measured).

I removed the RTC battery on the main board.

To Reproduce With a MEGA65 that has a non-ticking internal RTC (as reported my MEGAINFO):

1. Install the DS3231 external RTC with Grove cable and upgraded battery.
2. Turn on the MEGA65. Ensure that it is running core f555316 (v198); install this build to core slot 1 to such a core if it isn't. Confirm with MEGAINFO (with recent SD files, Freeze menu then Help key) or another method that the clock is ticking successfully.
3. Turn off the MEGA65. Hold Alt, turn on, then enter Configuration (1). Set the time and date using an hour value other than 19, then save and exit. Notice that the clock has the time that you set, including the hour value, but is not ticking because it is using the factory core.
4. Turn off the MEGA65, then turn it on again to run the latest core from slot 1. Notice that the clock is now fully functional except it shows an hour value of 19.
5. Reboot into the Configuration utility. Notice that the Configuration UI also now believes the hour is 19.

Expected behavior The hour should match what was set, and advance correctly with the rest of the time values.

[grim-fandango]

Even though the hours are stuck at 19 on the MEGA65, I've noticed that the date advances still - which suggests that the RTC has a sense of what the hours are. My guess is that the MEGA65 always sets the hours to 19 and reads the hours as 19. I'll test this and report back

[dansanderson]

I have confirmed that the battery of my DS3231 is only reading about 0.8V. I will pursue the recommendation to use a soldering iron to connect a more reliable 3V source, then re-test.

[dansanderson]

I have installed core 198 (f555316), and have upgraded the battery on my DS3231 to a CR2032 that measures 2.6V with the same polarity as the previous battery. I have used MEGAINFO to confirm that it is using the external RTC and it is ticking. I have used the Configuration utility to set the time (17:32:40 as I write this); doing so boots into the factory core, so I power off, then power on. The time now reads 19:35:11.

I am now in full agreement with @grim-fandango : There seems to be something peculiar setting the hour to 19, while preserving the other date and time values. Everything else seems to be working with the external RTC, including battery backup of the time. This is true even with the battery on the main board removed.

[dansanderson]

(Updated issue title and description.)

[dansanderson]

I left the MEGA65 powered on starting at "19":37:34, and the time now reads "19:04:18". So the "19" is being forced in real time; it doesn't tick over to 20.

[gardners]

Please try POKE $FFD7402,<something other than $19> from BASIC65, and report if it changes the hours.

[dansanderson]

POKE $FFD7402,$03
?TI$
03:40:59

Yes, the POKE updates the hours. This value survives the reset button, but not a power cycle: turning the machine off then on again sets the hour back to 19.

(I'll set it to 03 again and wait 20 minutes for the top of the hour, just in case that's interesting. :) )

[dansanderson]

New data point: I set the hour to $03 with the POKE and let the minutes roll over. The hour value stayed at 03.

?TI$
03:49:24

?TI$
03:01:38

[grim-fandango]

Well, I watched the date all day yesterday, and 15 hours later it still hadn't changed, but then I was just too tired to wait another hour :-) This morning the date has changed, so at some point the date has incremented. I've just tried setting the time to 2355 to see if the date flipped at 'midnight', but it didn't. Very peculiar!

[grim-fandango]

Another observation: when in MegaInfo, it detects the RTC, and says "CHECKING". It then starts displaying the time. If you want until the top of the hour, it says CHECKING again, when you wouldn't expect it to. Just noting that here in case that was an indicator of something

[dansanderson]

A clue from a troubleshooting session with Paul in Discord: the hour value survives the reset button, but not the FPGA reset poke. This indicates bad initialization.

Set the hour value and confirm it is set:

POKE $FFD7402,$10:?TI$

FPGA reset into core slot 1:

POKE $FFD36C9,$40:POKE $FFD36CF,$42

This resets the hour to 19.

We could see this from the Alt menu via the serial monitor: set the hour value again, power off, hold Alt, power on to get to the Hypervisor menu with core 0. Hold Alt on the MEGA, then In the serial monitor:

sffd36c9 40
sffd36cf 42

This resets to the menu again with core 1. Confirm this in the serial output, then test the hour value with mffd7402. I saw:

MEGA65 Serial Monitor
build GIT: development,20220623.13,f555316

.:0FFD7402:1901080722000000000000001C08001C

(See the "19" at the beginning.)

[dansanderson]

FYI this issue persists in RC 0.95 core dadad1c. (I'm not aware that anyone submitted a fix, just saying it will continue to be an issue if not fixed for RC 0.95.)

[lydon42]

Another observation: when in MegaInfo, it detects the RTC, and says "CHECKING". It then starts displaying the time. If you want until the top of the hour, it says CHECKING again, when you wouldn't expect it to. Just noting that here in case that was an indicator of something

This is expected, MEGAINFO can only do between 1-2 hours of tracking, then the counter will run over and it will start detecting again.

[Niborski]

it however also does this when starting MEGAINFO just 1 minute before rollover. Reverts to checking and the hour does not rollover.

[lydon42]

F1 enables debug output in the bottom row...

[lydon42]

And to summarize my investigation today: I can't see any place where the RTC hours get set to 19, nor where the RTC gets totally reset. Looked into hyppo and i2c vhdl.

[lydon42]

The part where the 19 can be found is the signal initialization in grove_i2c.vhdl (0x99 & 0x3f = 0x19):

  signal write_job_pending : std_logic := '0';
  signal write_reg : unsigned(7 downto 0) := x"02";
  signal write_val : unsigned(7 downto 0) := x"99";

But write_job_pending is 0, so it is unclear to me why it is writing it on startup.

Quick fix will be implemented by changing write_reg to 0d, which will write to the second alarm day register instead. As alarm features are unused, this will solve the clock hour 19 problem, but it is obviously not the final solution to the problem.