TDS340/360 DS1644 RTC oddity--both WRITE & READ bits set for reads and wr ops

[ChuckDarwin]

Back to working through my "someday shelf”—
TDS340 (not 340A if that matters) modified to a TDS360 with battery socket added, too.  FW 1.07.  I believe the following condition existed before the mod based on notes, but I am not positive as some time has passed since the initial mod.  Observed problem: when the date/time display is enabled (Display/Readout Options), the display with show a static date/time reflecting the time at which it was enabled for display, it does not increment.  From initial debugging, this appears to be due to firmware setting both the DS1644’s RTC clock control READ and WRITE flags when executing an RTC read (or write), rather than only one or the other.  WRITE is going to load whatever is in the external facing date/time registers back into clock.  Poll the clock rapidly enough with WRITE set/unset and you effectively keep the clock set to the same time.  My first TDS went out the door a while ago so I don’t have a comparison handy.

I didn’t find anything searching, but if this is known issue, disregard details below.

When there are no read or write requests to the TDS’s DS1644 RTC, the RTC increments correctly—when the TDS is powered off or when the date/time is not being displayed on the screen, for example.  In the latter case, there is a slight loss over a day, so something may be polling the clock anyway.  This can be observed by querying the time via GPIB or toggling the date/time display on and off several times and noting an increment. 

However, when the date/time readout display on the TDS is enabled, the displayed time is static reflecting the time the date/time display was enabled.  Querying the time via GPIB shows an unchanging time.  Manually setting a new time via GPIB (TIME “HH:MM:SS”), the newly entered time will be reflected on the display and also when querying the RTC via GPIB again, but the clock does not advance past the newly set time.  Running with the date/time display off again, the clock will reflect the time lost when the date/time display was active. 

To read the DS1644 RTC, one would typically set the DS1644’s clock READ bit flag to let the internal clock update but freeze the output of the external facing RTC registers (addressable memory locations in this case), read the date and/or time, and then clear the read flag to resume normal register updates.  The WRITE flag along with setting the date/time registers with a new time value would be used to update the date/time safely.  These are the DS1644’s clock specific flags, not the chip write enable (/WE). 

On monitoring the DS1644 activity while in the TDS, it appears that this TDS sets both the DS1644’s clock control WRITE and READ bits (DS1644 addr 7FF8.7 and 7FF8.6) when executing a time read, rather than just the READ bit to pause clock output registers leaving the clock updating internally.  Using the WRITE bit effectively resets the clock to the time of the write operation—it reads the date/time registers holding the last time before the bit set if I recall correctly.  This behaviour was seen on two DS1644 and a DS1744 tested in the TDS.  The odd TDS polling read happens frequently enough when the date/time display is enabled that the clock appears to update itself with the same time over and over, outwardly appearing to stay in a static-like state.  When reading or writing the clock from GPIB, both the WRITE and READ bits are set as well, but immediately released upon the read or write as it is a one-time event and not a constant poll.  If I disconnect the data line (D7) associated with the WRITE control bit after enabling the on-screen date/time display, the clock displayed on the screen updates—albeit with the loss of the high bit for all data read/writes.

Basic checks: The read (D6) and write (D7) data lines for the bits in question do operate independently (not shorted).  DS1644 Vcc and battery voltages are good.  I have tried two DS1644s and a DS1744 with the same results.  Used a programmer with one of the DS1644s to replicate this outside the TDS.  The OSCillator stop bit on the DS1644 (7FF9.7) is not being set which was my first thought (set the OSC stop flag when storing to save the battery).  I am leaning towards some firmware related issue/corruption.

Off in the wrong pasture?
Is there a firmware update tool for the TDS340/460 to try a reflash?