I have three HP3468A multimeters, and as has been discussed on this forum, the Control ROM in these meters are prone to random failure. So I'd like to read out the contents of the ROMs in my units in case that ever happens.
https://www.eevblog.com/forum/testgear/hp-3468a-owners-unite-a-storm-is-coming!/
They maintain calibration data in a RAM chip that is powered by a lithium battery when the units are not powered on. And I'd also like to save that information before the batteries fail (or I stuff something up).
My plan was to wire an Ardunio into the meter and actively drive the address and control lines of the ROM and RAM chips, while reading what comes out on the data pins. However, this is not possible since some of the signals that need to be driven would conflict with the existing drive source for these pins. So another approach was needed.
Since the units perform a checksum test of both the ROM and RAM during the startup self test, it should be possible to simply monitor and record the bus activity during this time. This has been mentioned here before also [somewhere that I now cannot find]
This could be done easily with a logic analyzer, but I don't have one (that's any good).
However, that's no problem because the AVR processor can be used for this instead. (not as an Arduino - it needs to be programmed in assembler to get the speed and memory space needed). It also has some advantages over (affordable) logic analyzers:-
* Up to 30 channels (most cheapish LAs seem to be 16 channels)
* Channels can be outputs if required (maybe some LAs can do this, I don't know)
The output capability is useful to reset the HP3468 prior to monitoring the buses.
Rather than trying to program the AVR to watch the bus activity and build up an internal image of the ROM and RAM for subsequent upload to a PC, I elected to simply record everything (like an LA) and upload this trace data to the PC instead.
Initially, this made sense for me, since I wasn't sure what this bus activity would look like, and therefore what to watch for to build up the internal images. And I have now extracted the ROM and RAM contents from the trace data, so there is no need for the other method now.
But with what I know now, an AVR program to simply build up the images and upload them to a PC would be fairly simple. Maybe I should still do that as well, it would be much faster and more straightforward to use.
The trace data is still valuable because it has other uses, but more on that later.
Looking at the diagrams below, nearly all the signals needed are on the control ROM, four others required are on the 8039 processor, and one is on U505 (plus ground).

How this was wired to the AVR.

Here's the test setup. I soldered square header pins to all pins but VCC on the ROM, plus various others.

Close up

The program in the AVR accepts simple single character commands, with some needing additional values in hex or decimal.
When told to begin recording, it uses an output pin to reset the 8039, then spins on the ROM's -CE signal (or the RAM's OD signal), waiting for it to go low (active). It then reads the address bus, some control signals, and after a short delay for the ROM/RAM access time, grabs the now valid data as well. This 4 byte sample is saved to the AVR's internal RAM buffer, and it then waits for the trigger signal to go high again. This process repeats until 4000 samples have been acquired, and the PC is then notified to upload the buffer.
The control program on PC uploads the trace samples, then tells the AVR to capture another sample block, but this time specifies that a certain address must be seen on the bus before recording, and also that this address must be hit a given number of times before recording is enabled. This activation address and count come from the last sample previously uploaded. So in effect, each sample block is recorded by starting the 8039 from reset, then waiting until it gets to where the previous sample block left off, then starting to record from there.
To get to the point where all the ROM data have become available from the startup self test takes about 328000 samples or 82 sample blocks. That takes about 5 minutes to do, uploading at 250K baud. At first I was using 57600 baud, and it took almost an hour. The Calibration RAM data is all captured in a single sample block.
Although the HP3468 has only a 13 bit address bus, the recorded samples have 16 bits of address, to make it more general purpose.
(I have a couple of 6809-based systems that I might want to use this on...)
Not all the calibration RAM seems to be used. Here's what I found (data is only 4 bit nibbles):-
0 1 2 3 4 5 6 7 8 9 A B C D E F
00 . . . . . . . . . . . . . . . . locations with "." were not accessed
10 9 9 9 9 9 8 5 0 E 3 C C E 7 D B
20 9 9 9 9 9 9 9 0 E 2 2 D F 5 C 3
30 0 0 0 0 0 0 8 0 D 4 F C F D 4 C
40 0 0 0 0 0 0 1 0 D 4 B 1 F D 4 0
50 0 0 0 0 0 4 8 0 B 2 0 0 B E 4 B
60 0 0 0 0 6 9 4 0 1 C 0 5 0 3 5 F
70 0 0 0 0 0 6 8 0 1 C D C 9 B 5 4
80 0 0 0 0 0 0 5 0 0 3 1 5 F D F 4
90 0 0 0 0 0 0 1 0 1 B 0 3 F 7 4 C
A0 0 0 0 0 0 0 1 0 0 1 5 C F 6 6 F
B0 0 0 0 0 0 0 0 0 1 4 F E F B C 8
C0 0 0 0 0 0 0 9 0 0 D 0 2 F 9 E B
D0 . . . . . . . . . . . . . . . .
E0 . . . . . . . . . . . . . . . .
F0 . . . . . . . . . . . . . . . 0
This looks similar to what someone else extracted here:-
[another somewhere that I now cannot find]
I think from user"sailor", who has not been active here since 2017 and has not responded to my PM on the 3468. (He's alright I hope)
Other trace sampling runs can be made without resetting the 8039, to record normal operation of the HP3468 in various modes (voltage, current, resistance, etc)
Until now I have only found one ROM image for the HP3468A on the web, and while mine is similar (exact in many areas), it is a different version. The unit this was done with is from about 1982, whereas my other two units are from 1991 & 1993. Maybe they have the other version of the ROM in them. I'll find out when I repeat the process for them.
If anyone is interested, I'll make this version of the ROM contents available.
A couple of years ago I wrote an intelligent, interactive dissassmbler for the MCS-48 processor family (of which the 8039 used in the HP3468 is a member). I put a huge amount of effort into that, way more than I can properly justify - too much time on my hands. And I've recently spent a whole lot more time on it, to make use of the trace data. This has already been a huge help in understanding the control firmware, since I can see which parts of it are actually executed, and even single-step through the source code. The trace data really helps identify if ambiguous areas in the ROM are code or data. Code that is accessed indirectly is typically a massive stumbling block for disassemblers, but the trace data shows how and where from, an otherwise isolated piece of code was entered. The MCS-48 architecure is fairly weird, and complicates the disassembly process, and the way that HP used the 8039 makes unraveling the code even harder. I've still got a long way to go on this... (collaborators?)
Ultimately, what I'd love to do with these units is fully understand the ROM disassenbly, especially those parts that deal with the core analog meter functionality (ADC, switching, Cal, etc).
Then throw away the Processor, ROM, Cal RAM, battery, crystal and a few other chips, plus the whole front panel.
Put a socket where the CPU is, with a daughter board plugged into it, containing an AVR, and a cable going to a replacement front panel, with a big pretty OLED display, illuminated buttons, and shrouded input terminals. (I can dream can't I?...)
Replacing the front panel with something like that can probably still be done while keeping the existing processor. That would still benefit from understanding the firmware.
Video about all this:-