HP3468A - Reading the Control ROM and Calibration RAM by bus monitoring - Page 1
Forum section: electronics / testgear

author: intabits
author_rank: Frequent Contributor
timestamp: April 08, 2021, 03:32:30 pm
content: 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 upThe 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):-Code:0 1 2 3 4 5 6 7 8 9 A B C D E F00 . . . . . . . . . . . . . . . . locations with "." were not accessed10 9 9 9 9 9 8 5 0 E 3 C C E 7 D B20 9 9 9 9 9 9 9 0 E 2 2 D F 5 C 330 0 0 0 0 0 0 8 0 D 4 F C F D 4 C40 0 0 0 0 0 0 1 0 D 4 B 1 F D 4 050 0 0 0 0 0 4 8 0 B 2 0 0 B E 4 B60 0 0 0 0 6 9 4 0 1 C 0 5 0 3 5 F70 0 0 0 0 0 6 8 0 1 C D C 9 B 5 480 0 0 0 0 0 0 5 0 0 3 1 5 F D F 490 0 0 0 0 0 0 1 0 1 B 0 3 F 7 4 CA0 0 0 0 0 0 0 1 0 0 1 5 C F 6 6 FB0 0 0 0 0 0 0 0 0 1 4 F E F B C 8C0 0 0 0 0 0 0 9 0 0 D 0 2 F 9 E BD0 . . . . . . . . . . . . . . . .E0 . . . . . . . . . . . . . . . .F0 . . . . . . . . . . . . . . . 0This 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:-

author: Hydron
author_rank: Super Contributor
timestamp: April 08, 2021, 04:20:18 pm
content: I had a similar desire for my Keithley 236 SMU - I wanted to read out the (non-socketed) calibration EEPROM for safekeeping as it seemed to be in a reasonable state of calibration for the current source/measurement, and re-calibration would be very difficult with the equipment I have on hand (voltage was off but that's easy to re-calibrate with a good DMM). ROMs are socketed and images are available online so I didn't need to worry about those.I ended up making use of the power-on checksum (and another mem-test that you can command from a menu) as you mentioned - the EEPROM is 2k*8 but luckily only 9 bits of address are actually used, so 9 address + 8 data + 3 control = 20 lines in total, which I could _just_ manage with the 4 analogue and 16 digital channels of my mixed-signal scope.It took a bit of ugly CSV/spreadsheet hackery (writing some python would probably have been better in retrospect) but I got the data I wanted, and it even matched the checksum, so I would second the suggestion that bus monitoring is worth trying for situations like this (especially where enough LA channels are available).Attached cable nightmare photo may be of interest

author: intabits
author_rank: Frequent Contributor
timestamp: April 09, 2021, 04:01:02 pm
content: Quote from: Hydron on April 08, 2021, 04:20:18 pmNightmare indeed, but they seem to be much higher quality probes than I've ever had the pleasure to use.I would always be worried that the cheap crap that I know would be making flakey contact, or shorting pins together if I even looked at it the wrong way.The soldered pin extensions and dupont wires I used above are certainly invasive, and not always practical, but give a relatively robust connection. Especially if stuff can't move about.

author: Hydron
author_rank: Super Contributor
timestamp: April 09, 2021, 05:36:12 pm
content: Most of the probe clip things there were tektronix parts - got a bag of NOS ones from (US) eBay at $35 for 20, wish I'd bought more now as they're excellent (and it was a hassle getting them from the US). There are a couple of "EZ Hook"s in use too that came with the scope, but they didn't work as well for clipping around DIP legs. Best choice would probably be a purpose made DIP package clip thing, but I don't have one (thought after that effort I'd buy one if it were a regular need).

author: cruff
author_rank: Regular Contributor
timestamp: April 10, 2021, 04:01:55 pm
content: This threadhttps://www.hpmuseum.org/forum/thread-8061.htmlcontains information about the cal RAM contents including ways to read/write it from the HP-IL and to decode it.

author: intabits
author_rank: Frequent Contributor
timestamp: April 11, 2021, 01:29:28 pm
content: Thank-you for that link.It's already been of help in identifying code in the ROM!

author: jlp1167
author_rank: Newbie
timestamp: December 20, 2021, 12:16:02 am
content: Can someone provide the bin for the eprom of this instrument? Mine just took a dump

author: pqass
author_rank: Super Contributor
timestamp: December 20, 2021, 01:45:08 am
content: Quote from: jlp1167 on December 20, 2021, 12:16:02 amSee this threadhttps://www.eevblog.com/forum/testgear/hp-3468a-owners-unite-a-storm-is-coming!/Post #74 bottom of page 3 there is a hex and bin of U502; not sure if they're talking about the '68 or '56.

author: intabits
author_rank: Frequent Contributor
timestamp: December 20, 2021, 01:38:50 pm
content: Quote from: jlp1167 on December 20, 2021, 12:16:02 amHere are the two ROM images that I have.

author: jlp1167
author_rank: Newbie
timestamp: December 20, 2021, 05:40:27 pm
content: Which one works?ahh I notice dates - so based on a serial number - me thinking out loud this morning.I'll try them both and post my serial number for which ones work with mines! ..thank you!

author: dfrederickson
author_rank: Contributor
timestamp: December 28, 2024, 05:17:29 pm
content: Seems like a lot of work. The 3468's CAL RAM can be read the same as the 3421.https://www.eevblog.com/forum/repair/hp-3421a-cal-ram/msg1174246/#msg1174246