Dumping and restoring the CAL RAM of an HP3457A

[0xfede]

Hello all,

I'm not sure if this topic belong to this section so please bear with me.

Just a couple of week ago I bought a wonderful HP 3457A from another EEVBLOG user. It turns out that the meter agree with just few PPM error from my calibrated 34465A in DCV. The problem I faced is that there is no documented way to dump the CAL RAM and I hate to watch a ticking time bomb waiting to do what it is designed for. I know there is a procedure to change the battery while the meter is powered on but I'm a little scared of doing live surgery without a backup.

My first step was to download the firmware from KO4BB site (luckily is the same version of the one in my DMM, link: http://www.ko4bb.com/manuals/79.56.219.91/HP_3457A_88810_8707_EPROM.bin ) and then I disassembled it using a nice utility called f9dasm ( http://www.hermannseib.com/english/opensource.htm ).
After a couple of hour I found what I was looking for, a list of unkonwn/undocumented commands:

• CIIL value
• CIIL?
• TAIL
• KEY?
• PEEK address
• POKE  address,value

Of course the latest two are the most interesting and in particular PEEK seems perfect for the job. It accepts only the range from 0 to 32767 and return a decimal number containing two byte (value@address and value@(address +1)). It cannot address all the memory but since the memory map is:

• UART 0x00 to 0x1F
• HPIB 0x20 to 0x27
• CXTRIG 0x28
• CALREQ 0x30
• I/O 0x38 to 0x3F
• CALRAM 0x40 to 0x1FF
• RAM 0x200 to 0x1FFF
• ROM 0x2000 to 0xFFFF

we can download the CAL RAM without problems.
Code snippet:

5  TRIG 4
10 FOR I = 64 TO 512 STEP 2
20 PEEK I
30 NEXT I

returns all the CAL RAM values (this program probably will not work on earlier HW/FW revision of the Main Controller board due to different memory scheme).

As I said the data format is a bit odd since it consist of two bytes printed in decimal. For example PEEK 64 returns 7.5720000E+03 that means 0x1D@64 and 0x94@65. After reordering all the byte I found as expexted that all data between 0x2000 and 0x7FFF corresponds exactly to the ROM bin file. It should also been noted that PEEK 10, PEEK 12 and PEEK 14 throws the horrible message "HARDWARE ERR" on the instrument display (maybe a killer POKE?) and should not be used.

The next step is to try a POKE command on the CAL RAM (I tried it only on the standard RAM address due to lack of courage) and I will let you informed with the progress.

Attached you will find a complete binary dump (0 to 32767) just for reference.

Best,
0xfede

EDIT: added the TRIG 4 command to stop any acquisition process to avoid mixing reading values with RAM data.

[BradC]

I'll be interested to see how you go putting it back, because the 3457a has some fairly onerous requirements to unlock its hardware write protect on the cal-ram.

Check section 8-47 "Writing to the protected section of RAM U511" starting on Page 8-20 of the service manual, specifically "CAL-RAM Lock circuit operation" which describes how the WE of the RAM is unlocked. It appears quite challenging without some serious software assistance. Of course I wouldn't be that surprised to see some undocumented debug code in there to do it, but it would be peculiar to go to those lengths to protect the cal data and the leave code in there that would compromise that effort.

[0xfede]

I'll be interested to see how you go putting it back, because the 3457a has some fairly onerous requirements to unlock its hardware write protect on the cal-ram.

Check section 8-47 "Writing to the protected section of RAM U511" starting on Page 8-20 of the service manual, specifically "CAL-RAM Lock circuit operation" which describes how the WE of the RAM is unlocked. It appears quite challenging without some serious software assistance. Of course I wouldn't be that surprised to see some undocumented debug code in there to do it, but it would be peculiar to go to those lengths to protect the cal data and the leave code in there that would compromise that effort.

Sorry to inform you that you are looking for the early revision Main Controller (it has a different memory address scheme). As I stated I don't think that what I wrote is compatible with it. For the newer revision (8-68A/8-68B and 8-67/8-68) you have just to write @ address 0x30 that is wired to CALREQ and before 4.096ms write the new value.

Which Main Controller do you have?

[BradC]

For the newer revision (8-68A/8-68B and 8-67/8-68) you have just to write @ address 0x30 that is wired to CALREQ and before 4.096ms write the new value.

Sorry, then you should check 8-53 "Writing to the protected section of RAM U603" on Page 8-25 for the new version.

I'm not quite sure you've understood the description or circuit, as you have to hit CALREQ between 4.096 & 4.1ms after counters U631, 632A & 632B are reset. They form both the watchdog and the CALRAM timing circuit, so you need to reset the processor *then* hit CALREQ in the timing window to unlock the CALRAM. Check out the gating surrounding timer U631. The CALRAM unlock window is opened when bit 13 goes high, and is closed when bit 3 goes high. That is then gated around U635a such that there is only a valid unlock if CALREQ is made active during that window. If it's active early, or misses the window then it remains locked until the next hardware reset.

My meter is the newer revision, but it's not really relevant. The memory maps are to all intents and purposes identical, as is the CALRAM unlock procedure.

[0xfede]

For the newer revision (8-68A/8-68B and 8-67/8-68) you have just to write @ address 0x30 that is wired to CALREQ and before 4.096ms write the new value.

Sorry, then you should check 8-53 "Writing to the protected section of RAM U603" on Page 8-25 for the new version.

I'm not quite sure you've understood the description or circuit, as you have to hit CALREQ between 4.096 & 4.1ms after counters U631, 632A & 632B are reset. They form both the watchdog and the CALRAM timing circuit, so you need to reset the processor *then* hit CALREQ in the timing window to unlock the CALRAM. Check out the gating surrounding timer U631. The CALRAM unlock window is opened when bit 13 goes high, and is closed when bit 3 goes high. That is then gated around U635a such that there is only a valid unlock if CALREQ is made active during that window. If it's active early, or misses the window then it remains locked until the next hardware reset.

My meter is the newer revision, but it's not really relevant. The memory maps are to all intents and purposes identical, as is the CALRAM unlock procedure.

Thank you for clarifying this. I know what is written in the service manual but if you look more carefully at the schematic of the first revision board and in particular the two address decoder U512/U513 (74ls138) the memory scheme is:

• I/O: 0x0000 to 0x17FF
• GPIB: 0x1800 to 0x1FFF
• UART: 0x2000 to 0x3FFF
• RAM: 0x4800 to 0x4FFF
• NVRAM: 0x5000 to 0x57FF
• CALREQ: 0x5800
• ROM: 0x8000 to 0xFFFF
• ....

The two address decoders are wired to A11~A15 on the early revision board and A1~A5 on newer PCB.
This means that the address scheme is completely different.

I'm still disassembling the POKE command to see how it write and if it manage automatically the CALREQ pin. In the meantime you can backup (as I already done) your instrument until I or someone else come up with a complete writing solution.

Best,
0xfede

[kj7e]

Not to take away from your nice work exploring the CALRAM.  Changing out the battery live really is not that hard, I did mine last week using a battery powered iron.  Cut the leads of the old battery and removed, then removed the old leads from the board, installed new battery.  The meter did make a few beeps and some that was concerning, but nothing was lost.  I used a Tadiran TL-5955/P, now its good for at least another 8 to 10 years.  Also did a 3478a at the same time.

[0xfede]

Not to take away from your nice work exploring the CALRAM.  Changing out the battery live really is not that hard, I did mine last week using a battery powered iron.  Cut the leads of the old battery and removed, then removed the old leads from the board, installed new battery.  The meter did make a few beeps and some that was concerning, but nothing was lost.  I used a Tadiran TL-5955/P, now its good for at least another 8 to 10 years.  Also did a 3478a at the same time.

Thank you kj7e. I already looked at a few posts about changing the CAL RAM battery and I'm not completely confident that I will not end screwing everithing up. I've already ordered the panasonic BR2/3A and in the meantime I'll dig further into the CALRAM writing process. It must be noted that I'm a bit rusty in disassembling the 6809 language but I am starting to remember what it means.

Best,
0xfede

[Magnificent Bastard]

@0xfede:

There must be a way to unlock the CALRAM already in firmware, because you can calibrate the meter from the front panel and through GPIB.  There might be a way to use that built-in code to accomplish what you want to do, but it is going to take some effort to "hack" the machine.

Another way is to read the contents of the CALRAM, then pull the RAM chip and replace it with a ("no battery needed") non-volatile chip (NVRAM) that is programmed with the calibration data.  The type of chip you use depends on whether the CS line goes low (after the address becomes valid) with every access-- (or not).  Old-school CMOS RAM chips are just fine with tying the CS line low, and only changing the address lines-- newer NVRAM chips (FRAM, and some others) latch the address lines when CS goes low (becomes active).

I haven't looked at the schematic, but I suspect that if they have some kind of write-protect scheme, then the CS line will indeed toggle low with each access.  You could check this in the schematic and verify with a 'scope.  If the CS line does toggle with every access, then you can replace the CMOS RAM with a FRAM chip (also now from Cypress).  If the CS line does NOT toggle with every access, something like a Cypress NVSRAM might work (the type that writes the RAM to EEPROM during power-down, and reads the EEPROM into RAM after power-up-- all done quickly in hardware).

If you can replace the old-school battery backed CMOS RAM with one of the above newer technologies, you will never have to worry about the battery in your DMM ever again (in fact you can remove the battery permanently I think, unless it is needed for something else).

Also, thank you for sharing your discovery of how to read the CALRAM on this forum-- that will help a lot of people!

*** EDIT *** ::

After looking at the schematic, and some data sheets, it appears that the FM16W08 will work just fine, but it will need a special DIP adapter to be made, and there must be a way (somehow) to get the CAL data into the chip before it is installed.  Only 1/4 of the chip is actually used (the top 2 address bits are tied low).  It is likely that most chip programmers will not be able to program this device properly, because it needs a lot of time after power-up before you start accessing the chip (probably internal charge-pumps at work here).  So, maybe a DIY programmer made of a 40-pin PIC processor (or something similar) to read and write the chip via a serial port; this should be really easy to do.  You should add an RC filter (very small R, very big C) on the VDD line, as the FM16W08 does not like a very fast rise-time on it's VDD line.  This same chip (and adapter) can also be used for the 3458A.  It appears that once this new NVRAM is installed, the battery becomes redundant, and may should be removed.

[rigrunner]

Tektron has already done a battery removal and nvram mod. The thread is here https://www.eevblog.com/forum/metrology/geting-rid-of-the-battery-in-the-hp3457a/

[0xfede]

Just a small update:

with a PEEK 48 (or POKE 48,0) the CALREQ pin goes LOW as expected. The only thing that remain to be done is to force NVE LOW and I think I've found an hidden command to do that.
Stay tuned for updates.

Note: The command 'POKE address,data' accepts only one byte as per data input.

Best,
0xfede

[0xfede]

Another small update. I found another group of commands:
SP_CALL address (address range: 0~8191)
SP_PEEK value (value range: 0~255)
SP_POKE address, value (value/address range: 0~255)

The SP_CALL command is the most intriguing since it seems that it can load a custom program stored in RAM with POKE (it should be more or less like the BASIC SYS). The next is to write custom code to set low CALREQ, halt the watchdog and then load the CAL constants.

Best,
0xfede

[0xfede]

Just a quick and dirty solution for everyone who wants to restore the CAL RAM:

Locate R633 (10K) on the Main Controller PCB:



and then following this schematic:



add a switch and optionally a LED with an 820R in series:



After that I sent a couple of times PEEK 48 and then the NVE line went LOW. So with POKE 64,0 I screwed up the CAL RAM on purpose, started a self test that returned a "9 NOT CAL'D" then I loaded all the values back and after a self test everything went fine:



The dirty MOD in all its ugliness:



I know that this is less appealing than a full SW solution but at least I can try various FW mod without the risk of permanently loose the CAL RAM. Moreover this HW MOD is very easy to make. The only drawback is that you have to issue the POKE 48 (which set LOW the CALREQ pin) a few times to be sure to set LOW the NVE pin.

Best,
0xfede

[BradC]

I can't find a part number, but by the circuit it looks like comparator U636 has an open drain driver. Couldn't you just pull the comparator end of R633 high with a resistor < ~4.7K?

[0xfede]

I can't find a part number, but by the circuit it looks like comparator U636 has an open drain driver. Couldn't you just pull the comparator end of R633 high with a resistor < ~4.7K?

The comparator is an open collector one and your proposed modification should work fine (~3.4V high level). Of course someone must test it.

Best,
0xfede

[Magnificent Bastard]

This is quite valuable information.  It allows 3457A owners to make an archival copy of their DMM's CALRAM contents, and then if the battery ever loses power and the CAL data is lost, all that needs to be done is replace the battery and then re-program the CALRAM with the archived CAL data.  This will save about $400 I think...  (Now if we could do the same thing with a 3458A, that would be great!)

Also, for those that want to replace their CMOS SRAM (plus battery) CALRAM with a non-volatile memory chip, this will allow that chip to be programmed "in situ".

BIG THANKS to user @0xfede    

[0xfede]

Thank's for your kind words Magnificent Bastard.

During the development I wrote a simple C# app to manage both the dump and restore process that I want to share. It is intended for use with the PROLOGIX GPIB-USB or the like.
I will appreciate if someone will dump the CAL RAM and then share the binary file with me. This will help understanding how the CAL process works and the checksum calculation.

Best,
0xfede

EDIT:

....  (Now if we could do the same thing with a 3458A, that would be great!)
....

Well I'm pretty sure that with a little patience is possible to do the same with the 3458A and it is a long time dream to have one but I cannot justify the purchase. 

[texaspyro]

(Now if we could do the same thing with a 3458A, that would be great!)

Go to ke5fx.com and download the GPIB toolkit.  There is a 3458A cal ram dumper program that I wrote.  You need an external programmer to restore the data to a new chip.  The 3458A has a more sophisticated write protect function and the location of the routine to call to unlock the write protect is firmware dependent.

[Magnificent Bastard]

(Now if we could do the same thing with a 3458A, that would be great!)

Go to ke5fx.com and download the GPIB toolkit.  There is a 3458A cal ram dumper program that I wrote.  You need an external programmer to restore the data to a new chip.  The 3458A has a more sophisticated write protect function and the location of the routine to call to unlock the write protect is firmware dependent.

The technique to read the 3458A's CALRAM is known, but what I was wondering is if there is a way to POKE bytes into the 3458A's CALRAM (and the other two battery backed RAMs as well) if we temporarily disable the CALRAM write-lock (in hardware) as we are doing here with the 3457A ... ?  If not, then the external programmer method is The Way ...

[0xfede]

(Now if we could do the same thing with a 3458A, that would be great!)

Go to ke5fx.com and download the GPIB toolkit.  There is a 3458A cal ram dumper program that I wrote.  You need an external programmer to restore the data to a new chip.  The 3458A has a more sophisticated write protect function and the location of the routine to call to unlock the write protect is firmware dependent.

The technique to read the 3458A's CALRAM is known, but what I was wondering is if there is a way to POKE bytes into the 3458A's CALRAM (and the other two battery backed RAMs as well) if we temporarily disable the CALRAM write-lock (in hardware) as we are doing here with the 3457A ... ?  If not, then the external programmer method is The Way ...

From an HW perspective is even easier than the MOD on 3457A:
extract the jumper on JM132 and connect the center pin on the WRITE- net.
I don't have disassembled the FW but if there is an hidden GPIB write command that's all.

As I said I don't have a 3458A and I cannot test and confirm this procedure but it should work. Maybe in the future I may change my mind and buy a shiny 3458A?

[hazzer]

Morning 0xfede

I'm reading this post with much interest as I have a 3457a which is in need of a new battery - I don't have a prologix adaptor but I do have access to a HP 82357B USB GPIB adaptor. Could you expend on the need for the prologix adaptor? is there something inherent in this process that needs this adaptor? Might the 82357B support the peek & poke commands??

Hazzer

[0xfede]

Hi hazzer,

I'm pretty sure that with some modification the program should work with the HP USB adapter.
Right now I'm on holiday (700km away) and I'll be back in my lab on August 6.

Best,
0xfede

[maxwell3e10]

So what happens when the battery goes low? Does it just loose calibration or more serious trouble with other memory locations? My 3457A hasn't been calibrated since manufacture, so I thought I wouldn't worry about the battery and just calibrate it when it gets low.

[dl1640]

If one has access to a calibrator e.g. 55XX, no worry to lost the cal data because it can be calibrated (adjusted) after replacing the batt. Correct?

[hazzer]

Just looses the cal date, a new battery and a fresh cal and its all good again. Its great to have the old cal data to hand - the best DVM is the one that never needed to be tweeted.
Mine was last cal in June 99 and is still bang on.

[hazzer]

I decided to get the prologix adaptor - (there some bespoke software that will only run on it so no harm to add it to the workshop).

Hazzer

[dl1640]

My one has calnum? 34, but I dont know how to see the last caldate.

[maxwell3e10]

Calnum increases by one for each calibration point. I believe 34 corresponds to one complete calibration procedure, on my meter the calnum is also 34. It means the meter was just calibrated once when it was made.

[hazzer]

If you get a chance - a quick Q...
I now have the prologix adaptor - when I run the memory_dumper_3457A.exe (on a windows7 32bit laptop) I can see data fill the window and at the end the prog crashes with an error "Index was outside the bounds of the array".
Interestingly I get the same data to appear irrespective of the GPIB address set in in the utility.
I think I'm missing something here ....

Will start by reading the prologix manual... 

[hazzer]

Worked great, awesome to have the cal data backed up from my 3457A......

hazzer

[0xfede]

Worked great, awesome to have the cal data backed up from my 3457A......

hazzer

Hi hazzer,

so you succeded in dumping the CAL RAM?
Do you mind sharing the content?

Thanks in advance,
0xfede

[maxwell3e10]

hazzer,

I am curious what you did between your first and second message. I tried the program using Arduino emulator of the Prologix adapter and it behaves as you described in the first message. It sends the correct commands to the meter, but doesn't seem to get anything back. Manually I can get the same commands to return results from the meter.

[dl1640]

5  TRIG 4
10 FOR I = 64 TO 512 STEP 2
20 PEEK I
30 NEXT I

are these all we need to dump the content of CALRAM?
if so i will try to use my NI USB-GPIB to talk to the meter. 

[0xfede]

5  TRIG 4
10 FOR I = 64 TO 512 STEP 2
20 PEEK I
30 NEXT I

are these all we need to dump the content of CALRAM?
if so i will try to use my NI USB-GPIB to talk to the meter. 

It is just easy as that. The only thing left to do is to reorder data since each couple of bytes is packed in the response.

Best,
0xfede

[dl1640]

0xfede

i had trouble by sending "TRIG 4", it returns err.16
so i send "TRIG HOLD", it worked.

i attached my dumped CAL constants, FYI.

(i dont know how to re-order them by now)


EDIT:

I think my 3457 GPIB circuitry has some intermittent issue, so "TRIG 4" should work.

[sipo75]

I will add my dump. Will the dump work with this ROM version?

03457-88804 REV 4 WYLE LABS

[0xfede]

Probably it would not work. I think you have the older mainboard, sorry.
Nevertheless you should be able dumping it just by peeking between 0x5000 and 0x57FF:
5  TRIG 4
10 FOR I = 20480 TO 22528 STEP 2
20 PEEK I
30 NEXT I

Best,
0xfede

I will add my dump. Will the dump work with this ROM version?

03457-88804 REV 4 WYLE LABS

[sipo75]

Does this dump look plausible?

[Grippy]

Well I'm not sure if It's the right backup but here's my similar dump, also of a 03457-88804 REV 4 WYLE LABS ROM Version.

Also here's some horrible (but working) python code to dump a memory address range over GPIB. It should work independent of the cable, I tried both a National Instruments and an Agilent one. It does require some Python dependencies and also the National Instruments VISA back-end (all available online for free)

You just need to change the address to your GPIB address in the first few lines since I didn't add a prompt for it.

Code: [Select]

#HP 3457A Arbitrary Memory Dumper
#Andrei Aldea 2018
#Asks for Beginning and End Adress in Decimal to Read
#Reads twice, does MD5 checksum of the two files created and tells user if they match

import visa
import time
import hashlib
rm = visa.ResourceManager()
inst = rm.open_resource('GPIB0::22::INSTR')
inst.write('TRIG 4') #Freeze instrument so we can read from it

def peek_memory(f):
    for x in range(int(start_adress),int(end_adress)): #OR 64 to 512 for older ROM versions? 20480 to 22528 for newer

        try:
            the_str = "PEEK " + str(x) 
            print(the_str)
            inst.write (the_str)
            data = inst.read_bytes(14) #Read data 14  bytes at a time... ~ what the insrument returns
            #NOTE: Instrument always returns Engineering notation... so convert to  float then Int... 'cause why not.
            string_data = str(data).partition("'")[2].partition("'")[0] + '\n' #Split weird formatting and add a newline
            f.write(str(x) + ": " + str(int(float(string_data))) + "\n") #Write it's float equivalent to disk
            print(str(string_data) + " Or Decimal: " + str(int(float(string_data)))) #Print what was written
            pass
        except:
            print("Couldn't read after " + the_str)
            f.write("THIS IS BROKEN")
            f.close()
    f.close()

#Function to Get MD5 Sum
def md5(fname):
    hash_md5 = hashlib.md5()
    with open(fname, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            hash_md5.update(chunk)
    return hash_md5.hexdigest()

inst.write("ID?") #Ask the instrument what it is
print((str(inst.read_bytes(9)).partition("'")[2].partition("'")[0].partition('A')[0] + " Detected")) #Print instrument response

start_adress = input("Memory Start Adress (64 or 20480 reccomended): ")
end_adress = input("End Adress(512 or 22528 recommended, 65535 max): ")

#First Checksum

fname_1 = "3457_DUMP_" + str(int(time.time())) + ".txt"
f = open(fname_1, "w")
peek_memory(f);
checksum1 = md5(fname_1);

#Second Checksum
fname_2 = "3457_DUMP_" + str(int(time.time())) + ".txt"
f = open(fname_2, "w")
peek_memory(f);
checksum2 = md5(fname_2);

if(checksum1 == checksum2):
    print("Success!");
else:
    print("FAILED. MD5 Sums of Two Reads do not Match!")
    print(fname_1 + " MD5: " + str(checksum1))
    print(fname_2 + " MD5: " + str(checksum2))

Also changed the battery while I was at it... hopefully didn't lose Cal constants...

[ipqobk]

Hi, I tried to make a dump on my 3457A that uses the firmware and the board that I attach in photos, I use the PROLOGIX interface and HP3457A Memory Dumper.zip (Thank to 0xfede), I often have difficulty doing it with win10-64b where it goes wrong when saving the file , with win10-32b it makes the rescue regularly. The multimeter has the firmware 03457-88810 Rev2 (If someone interested I have the .bin of the eprom).
I noticed that if I do more 'dump and compare the content is different, only some parts match, do you have any advice to give me?

Best regards,
Paolo

[ipqobk]

When use the Memory Dumper on Windows 64bit this is the error that appears and what 'appears in the window of the dumper, later' I try to do the same reading on another pc always with win 10/64bit, Paolo

[ipqobk]

This is the comparison of the three dumps with win10 / 32bit

[ipqobk]

Now I tried to read the contents of the ram with Grippy's Arbitrary Memory Dumper (Thanks' Andrei Aldea), with Python 3.7.2 and VISA with the USB GPIB adapter F8235 from Beiming Technologies (nightpanda made it, compatible HP 82357) and windows10 / 64, I made two consecutive dumps that are identical.

[bingo600]

Now I tried to read the contents of the ram with Grippy's Arbitrary Memory Dumper (Thanks' Andrei Aldea), with Python 3.7.2 and VISA with the USB GPIB adapter F8235 from Beiming Technologies (nightpanda made it, compatible HP 82357) and windows10 / 64, I made two consecutive dumps that are identical.

Any pointers to nightpanda's work ?

/Bingo

[ipqobk]

nightpanda I believe is the owner of Beiming Technologies (bmjd.tech) that has realized the interface F8235 USB <> HPIB compatible with the HP82357 (https://groups.google.com/forum/?fromgroups#!forum/gpib-usb ), which I purchased around 2013/2014 and which I use to communicate with my instruments, as well as a prologix and an NI PCI-GPIB 488.2

Paolo

[pomonabill221]

I have the NI GPIB-USB-HS adaptor.  Will your wonderful utility use this adaptor, or is it only for the Prologic?  Thanks for your efforts!  Will come in handy and useful!

Anyone?

[tppc]

When use the Memory Dumper on Windows 64bit this is the error that appears and what 'appears in the window of the dumper, later' I try to do the same reading on another pc always with win 10/64bit, Paolo

Hi there,
I am facing the same issue with W10 64 bits.
Does anyone know a way to have this utility working under W10 64 bits?

PS. I tried it on W7 32 bits, W7 64 bits and W10 64 bits and it did NOT work, always the same issue.
- Did anyone ever successfully run this utility?
- Could the issue be related to a specific version of .NET framework?

Regards

[tppc]

Hi there,
The Memory Dumper works fine.
You just need to know that after pluging the GPIB - USB adapter, you need to configure it with Prologix.exe from the KE5FX GPIB toolkit
http://www.ke5fx.com/gpib/readme.htm



After doing so,  0xfede's Cal RAM utility works great!
THANK YOU.

Regards

[Tryer]

Hi 0xfede,
Thanks a lot for sharing all that information.
I have a 3457a for a few months now and have read your post with huge interest.
My device has a sticker "03457-88810 D/C 8949 REV 2"
The controller board is labeled 03457-66511 Rev.B
I must say that i could not find a schematic for that version.
The one i found, is for Rev. A
I have an ancient PC (ISA slots, win98). The GPIB card running on it,
is one of the reasons i keep it.
You remembered me on old times. My 1st computer was an Apple II with Applesoft basic.
Peeks and Pokes were very common.
I have written a small routine and now i am very happy to have a dump of the 3457's memory.
My eprom is an exact copy of your uploaded one.
So, i only upload the CALRAM area, if anyone want to compare.
I have a question that maybe you or somebody else could answer:
The memory map goes up to 0xFFFF. But the 3457 accepts addresses only up to 0x7FFE.
Why that?
Thanks again
Vos can exsisto rabidus per totum annum, after your discovery...

[0xfede]

Thanks for your kind words tryer.

The reason because 3457A memory peek goes only up to 0x7FFE is because they reused the float number output function to print the peek result in two bytes at time.  If you try peeking 0x7FFF it simply cannot display byte 0x8000 and refuse to do that.

Also thank you for the dump, it will be put in a good use.

μηδὲν ἄγαν.
0xfede 

Hi 0xfede,
Thanks a lot for sharing all that information.
I have a 3457a for a few months now and have read your post with huge interest.
My device has a sticker "03457-88810 D/C 8949 REV 2"
The controller board is labeled 03457-66511 Rev.B
I must say that i could not find a schematic for that version.
The one i found, is for Rev. A
I have an ancient PC (ISA slots, win98). The GPIB card running on it,
is one of the reasons i keep it.
You remembered me on old times. My 1st computer was an Apple II with Applesoft basic.
Peeks and Pokes were very common.
I have written a small routine and now i am very happy to have a dump of the 3457's memory.
My eprom is an exact copy of your uploaded one.
So, i only upload the CALRAM area, if anyone want to compare.
I have a question that maybe you or somebody else could answer:
The memory map goes up to 0xFFFF. But the 3457 accepts addresses only up to 0x7FFE.
Why that?
Thanks again
Vos can exsisto rabidus per totum annum, after your discovery...

[Tryer]

Hi 0xfede,
You mean, peek will work only for the low 32Kb of the memory?
I had the hope, that an additional action for "upper bank" switching would ne required.
Anyhow, this is not as important as the CALRAM dump. And your solution with the switch makes
the whole perfect!
You said "The only drawback is that you have to issue the POKE 48 (which set LOW the CALREQ pin) a few times to be sure to set LOW the NVE pin."
Anything new about that? Is some other routine setting it back?
I have not tried to test it yet.
My battery shows an continuous increasing voltage. Is it the sign before the eruption?
04.Jan 20 3.457V
20.Feb 20 3.474V
01.Apr 20 3.500V
25.Apr 20 3.504V
18.Mai 20 3.508V
Latest at 5V i will replace it.

Greetings, Tryer
 
ΕΝ ΟΙΔΑ ΟΤΙ ΟΥΔΕΝ ΟΙΔΑ

[0xfede]

By the way, you can find the schematic for the newer revision board here:
http://xrms.free.fr/divers/multimetre_HP_3457A_service_manual_reassembled.pdf

Ἄκουε τοῦ τὰ τέσσαρα ὦτα ἔχοντος

[Nuno_pt]

Hi 0xfede, can I use this to read the RAM < https://github.com/Twilight-Logic/AR488/blob/master/Contributed/artag/README.md > < https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg2718346/#msg2718346 > or do I need a know good GPIB.

Thanks for all the hard work

[Tryer]

I had that version already. But many thanks.
At the end, it is a big advantage being able to read.
Looking more carefully, i found in the right end corner of this pdf(p.228)
Rev.A
8-68A/8-68B

I hope the last line 8-68B means Rev. 8-68B

I will write a small routine (Borland C)
like:

for all calram bytes
{
  do
  {
    POKE 48,00 // may be 2-3 times that line
    poke adrs,byte1
    poke adrs+1,byte2
  } while peek(adrs) not as just written
  adrs = adrs+2
}

The switch must have been activated previously.
Of course this will be tested in the RAM area first.
Or shall i wait till the battery quits its service?
It itches anyhow.
 
Ἄκουε τοῦ τὰ τέσσαρα ὦτα και δεκατέσσαρα ὄμματα ἔχοντος **
** today (due to inflation? :-)) ) one says:"έχε τα μάτια σου δεκατέσσερα"
meaning something different namely "be carefull"

[Tryer]

@Nuno_pt
Any GPIB adapter (functional) will do.
It must be only capable to communicate with the 3457.
Can you communicate with any GPIB device using that interface?
I am very tempted to build this device. Have you built it?

[Nuno_pt]

@Hi Tryer, I'm still waiting on the boards.

I've some GPIB cables here and a few megas, so I can give a shot at disassembling a GPIB cable and plug it to a mega also.

[wiesl]

Hi, I tried to make a dump on my 3457A that uses the firmware and the board that I attach in photos, I use the PROLOGIX interface and HP3457A Memory Dumper.zip (Thank to 0xfede), I often have difficulty doing it with win10-64b where it goes wrong when saving the file , with win10-32b it makes the rescue regularly. The multimeter has the firmware 03457-88810 Rev2 (If someone interested I have the .bin of the eprom).
I noticed that if I do more 'dump and compare the content is different, only some parts match, do you have any advice to give me?

Hello,

Got my 3457A today, looks like it is in very good shape. Includes calibration certification until 10/2020. 10V voltage reference around -39uV off (9.99961V). Agilent 34410A shows exactly 10.00000V calibration valid until 10/2017. Which one would you trust?

Ad Cal Dumping: I experienced similar problems dumping the 3457A with HP3457A Memory Dumper.zip (Thank to 0xfede). I use the PROLOGIX interface under Win10-64Bit. Didn't try Win10-32Bit yet (no machine).

Serial number SN#: 2703A06XXX
Battery voltage of Saft Lithium LX1634 (looks original): 3.0328V
EPROM: 03457-88810, D/C 8825
Main Controller: 03457-66511 Rev A 88809F
Input Signal Conditioning, A/D Converter, Inguard Controller: 03457-66502 Rev C 88809F
AC Converter: 03457-66503 Rev B 88809F
Reference voltage board: 03456-66525 Rev B 88809F
Keyboard board: 03457-66505 8809F Rev A

Guess EPROM D/C 8825 means datecode year 1988/week 25, right (according to the chips datecodes and serialnumber/productrevision that looks ok)?

Cal Dump #1 has 451 bytes, Cal Dump #2 has 453 bytes.

Any ideas?
Something special to configure in the Prologix Setup?

BTW: Is it normal that the 4 screws of the Main Controller are missing (so it is not screwed)?

@0xfede: Any chance to release the source code of the dumper?
@ipqobk: I'm interested in the firmware 03457-88810 Rev2 dump. Whats the latest one for Rev. A boards?

Thnx.

Wiesl

[Tryer]

Hi wiesl,
There is a metal cover over the main controller with 4 screws, which fix both the cover and the controller.
Are you missing that cover?
As for the length of the CALRAM it is exactly 448 bytes (0x1FF - 0x40 + 1)

[wiesl]

Hi wiesl,
There is a metal cover over the main controller with 4 screws, which fix both the cover and the controller.
Are you missing that cover?
As for the length of the CALRAM it is exactly 448 bytes (0x1FF - 0x40 + 1)

No, cover and screws are there. Was too late yesterday, didn't think about that 

Yes, expecting exactly 448 but get more.

Wiesl

[wiesl]

Hi wiesl,
There is a metal cover over the main controller with 4 screws, which fix both the cover and the controller.
Are you missing that cover?
As for the length of the CALRAM it is exactly 448 bytes (0x1FF - 0x40 + 1)

Could read the calram (hopefully). Will post details later.

There is a forth interpreter in the HP3457A. Protection mechanism is discussed in the patent, too. Maybe that helps for a software solution.
See: https://patents.google.com/patent/US4747048
Forth interpreter discussed also at: https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg1185473/#msg1185473

Wiesl

[Tryer]

Attached a small script to read the CALRAM of the 3457.
It works for me with win7 64HE and the AR488 SW on an arduino Mega256 board.
Tested with Octave 5.2

[wiesl]

Could read the calram (hopefully). Will post details later.

Could read it hopefully.

I guess I found out how we can write to CALRAM in software only:

First of all an overview of the main controller board revisions:
- A1 Board: 03457-66501 Rev A
  - RAM: 0x4800 to 0x4FFF
  - NVRAM: 0x5000 to 0x57FF
  - Battery 3.0V
  - two address decoders are wired to A11~A15
- A11 Board: 03457-66511 Rev A (ERC<2850)
  - I own that board
  - CALRAM 0x40 to 0x1FF
  - Battery 3.0V, R644=17.4k, R645=13k
    - works well even with 3.6V battery with this resistor values
  - two address decoders are wired to A1~A5
- A11 Board: 03457-66511 Rev A (ERC>=2850)
  - CALRAM 0x40 to 0x1FF
  - Battery 3.4V, R644=13k, R645=12.7k
  - two address decoders are wired to A1~A5

Ad ERC:
- Does anyone know what ERC stands for (Equipment Revision Code)?
- Is the ERC sticker the one with "2749" or the one with "09-2839 Made in USA"?

How can we write to CAL-RAM (untested) in software only:
Signal OTL#: I/O Port OUT2 (0x3C) Bit7:
- OTL# positive Edge: resets counter U631 via U633A and U633B
- OTL#=1: sets U635B to 0 and therefore resets U635A and pulls NVE# low (as long as OTL#=1!!)

Wiesl

[Wim13]

I have a 03457-66501 the first model, and here are my results.

From the service manual section 8-40:

the CAL-RAM U511 is on this model on addres 5000 - 57FF for reading and is 2 Kbyte
The 2 Kbyte is also used for other data that has to be saved, so not only cal data,
cal data is only 512 bytes. U511 is in my unit a Toshiba TC5517APL

The unprotected write adresses are different for U511
in this case the manual says : write on 1000 - 17FF and read on 5000 - 57FF.
The other RAM U506 has same adress for read and write: 4800 - 4FFF.

The secure cal data should be on the high part of the U511 RAM
and are in the last 512 bytes: 5600 - 57FF (Read)
and write on adress 3E00 - 3FFF ( 512 bytes)

To check changes in U511 i did a dump 3 times, from the 2 Kbyte U511.
the second dump a day later and the third after a autocal.

I noticed, see attachment for the data, changes in the lower part of the RAM,
but not in the high 512 bytes location.

The last byte on U511 looks like the cal number, 35.

With the PEEK command you get 2 bytes in return, so for 2 Kbyte
you get 1024 lines with 2 bytes of info.

The Battery change: i took the A1 board out, connected 2 penlites (=3V)
by a diode to R557 for the moment, and changed easy the lithium backup batt.

[Wim13]

To make the dump complete, from the older device: HP 3457A, type: 03457-66501 Rev A.

here are all  binary dumps from:

the work RAM 2Kbyte, U506
the Cal Ram 2 kbyte, U511

The ROM 8 Kbyte, (TMM2365p) , U503
The EPROM 32 Kbyte (AM27256), U502, version 03457-88803

If some one has a copy of version 88804 or 88805, pls leave a dump.

Note, in the work ram you can see some of the peek command that were used.
 

 

[wiesl]

Which software version does your meter have?

[Labrat101]

Hi All
I have also just acquired a fully functional HP3457A
And I find this really interesting . I also got a dyeing Battery going to replace it soon.
Installed a Temporary patch battery 4.5v connected to the VMvcc line ( + diode & Resistor )
Holding the Cal Safe .

Great work

[Labrat101]

Hi All ,
I have reserved my dying battery that is date code 1992 . and is now holding around 3.26 volts.
with a 4.6v backup battery via diode & resistor connected to the  NVvcc  Node. so it does not interfere
with the Old 3v battery which is still good enough to keep the 3v ref to the Watch Dog.

My NVram is marked as Rev .2  U-602.  This is also displayed from the front panel command REV? 6,0
Being Not Programming minded at any level  .. Hardware I am OK on
Can one of you smart guys tell me can I do the cal dump on this NVram as per photo .
using the code that 0xfede very kindly put up.  .
and If Yes .Does the code have to be changed or altered in some way so it can be put back into the NVram ?
Sorry for seeming stupid but Programming and software is not my thing . Hardware I stick to Old School.

so cut a long story short I really want to backup my Cal as this hp3457A has a cal sticker 09/08/10.
All the reading are smack on compared to a 5 digit Instek and I am not worried if its a ppm out.
But to re Cal these 3457A costs $400 plus and the local cal lab said they can only cal to 6 digits ONLY
So my 3457A maybe better than there's  .

So any advice here I would really appreciate . I do have a plan "B"  and that's just to fit a 4.2v lithium rechargeable on NVvcc node and have it trickle charging while powered on and have a LED low voltage warning LED on the front panel and just keep the watch Dog happy with a coin 2032 battery. which is also probably enough to keep the NVram good for another 5 years or more if there is no other Hardware failures. Which will last me to My past expiry Date 

I also noticed that J614  looks like a Programming Plug as its marked RD & WR , 5v , Grd.
Marked in red .

Thanks .   

Update :: Adding the 4v plus but keeping below ideal 4.8v (5v) was recommend by another EEVblogger .
 Thanks.  Many thanks to "pqass"   

[Labrat101]

Hi Again,
After banging my head on the wall a few times I found a solution .
First thanks to  @ 0xfede for all the fantastic work and with the switch .
but I got bogged down with the software part .
I found an other EEVblogger  @ IanJ   has published a beautiful piece of work and a very nice
Program that works out the box even a non software guy understood it .

https://www.eevblog.com/forum/metrology/3458a-logging-via-windows-app-revisited/?all

it also has a Cal Read which I tried and it dumped the 448 bytes of cal memory with no problem
with my HP82357B . There is all the info on the link above  .

I have add the Dump bin  which looks very similar to some of the other cal dumps .