Dumping and restoring the CAL RAM of an HP3457A - Page 1
Forum section: electronics / general

author: 0xfede
author_rank: Regular Contributor
timestamp: February 04, 2018, 11:40:12 am
content: 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 valueCIIL?TAILKEY?PEEK addressPOKE address,valueOf 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 0x1FHPIB 0x20 to 0x27CXTRIG 0x28CALREQ 0x30I/O 0x38 to 0x3FCALRAM 0x40 to 0x1FFRAM 0x200 to 0x1FFFROM 0x2000 to 0xFFFFwe can download the CAL RAM without problems.Code snippet:5 TRIG 410 FOR I = 64 TO 512 STEP 220 PEEK I30 NEXT Ireturns 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,0xfedeEDIT: added the TRIG 4 command to stop any acquisition process to avoid mixing reading values with RAM data.

author: BradC
author_rank: Super Contributor
timestamp: February 04, 2018, 12:05:31 pm
content: 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.

author: 0xfede
author_rank: Regular Contributor
timestamp: February 04, 2018, 12:22:43 pm
content: Quote from: BradC on February 04, 2018, 12:05:31 pmSorry 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?

author: BradC
author_rank: Super Contributor
timestamp: February 04, 2018, 01:31:30 pm
content: Quote from: 0xfede on February 04, 2018, 12:22:43 pmSorry, 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.

author: 0xfede
author_rank: Regular Contributor
timestamp: February 04, 2018, 02:07:26 pm
content: Quote from: BradC on February 04, 2018, 01:31:30 pmThank 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 0x17FFGPIB: 0x1800 to 0x1FFFUART: 0x2000 to 0x3FFFRAM: 0x4800 to 0x4FFFNVRAM: 0x5000 to 0x57FFCALREQ: 0x5800ROM: 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

author: kj7e
author_rank: Frequent Contributor
timestamp: February 04, 2018, 02:58:32 pm
content: 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.

author: 0xfede
author_rank: Regular Contributor
timestamp: February 04, 2018, 03:12:39 pm
content: Quote from: kj7e on February 04, 2018, 02:58:32 pmThank 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

author: Magnificent Bastard
author_rank: Regular Contributor
timestamp: February 04, 2018, 04:00:16 pm
content: @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, andmayshouldbe removed.

author: rigrunner
author_rank: Frequent Contributor
timestamp: February 04, 2018, 06:51:26 pm
content: Tektron has already done a battery removal and nvram mod. The thread is herehttps://www.eevblog.com/forum/metrology/geting-rid-of-the-battery-in-the-hp3457a/

author: 0xfede
author_rank: Regular Contributor
timestamp: February 04, 2018, 07:18:07 pm
content: 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

author: 0xfede
author_rank: Regular Contributor
timestamp: February 05, 2018, 12:07:38 pm
content: 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

author: 0xfede
author_rank: Regular Contributor
timestamp: February 06, 2018, 08:10:46 pm
content: 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

author: BradC
author_rank: Super Contributor
timestamp: February 07, 2018, 01:10:44 am
content: 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?

author: 0xfede
author_rank: Regular Contributor
timestamp: February 07, 2018, 06:24:34 am
content: Quote from: BradC on February 07, 2018, 01:10:44 amThe 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

author: Magnificent Bastard
author_rank: Regular Contributor
timestamp: February 07, 2018, 03:06:57 pm
content: 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

author: 0xfede
author_rank: Regular Contributor
timestamp: February 07, 2018, 03:40:39 pm
content: 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,0xfedeEDIT:Quote from: Magnificent Bastard on February 07, 2018, 03:06:57 pmWell 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.

author: texaspyro
author_rank: Super Contributor
timestamp: February 07, 2018, 04:11:54 pm
content: Quote from: Magnificent Bastard on February 07, 2018, 03:06:57 pmGo 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.

author: Magnificent Bastard
author_rank: Regular Contributor
timestamp: February 07, 2018, 07:21:50 pm
content: Quote from: texaspyro on February 07, 2018, 04:11:54 pmThe 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 isThe Way...

author: 0xfede
author_rank: Regular Contributor
timestamp: February 08, 2018, 10:44:26 am
content: Quote from: Magnificent Bastard on February 07, 2018, 07:21:50 pmFrom 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?

author: hazzer
author_rank: Regular Contributor
timestamp: July 21, 2018, 09:11:47 am
content: Morning 0xfedeI'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

author: 0xfede
author_rank: Regular Contributor
timestamp: July 22, 2018, 05:30:19 pm
content: 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

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: July 22, 2018, 07:36:58 pm
content: 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.

author: dl1640
author_rank: Regular Contributor
timestamp: July 24, 2018, 12:37:34 pm
content: 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?

author: hazzer
author_rank: Regular Contributor
timestamp: July 26, 2018, 05:12:01 pm
content: 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.

author: hazzer
author_rank: Regular Contributor
timestamp: July 26, 2018, 05:17:01 pm
content: 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

author: dl1640
author_rank: Regular Contributor
timestamp: July 27, 2018, 12:51:07 am
content: My one has calnum? 34, but I dont know how to see the last caldate.

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: July 27, 2018, 03:45:32 pm
content: 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.

author: hazzer
author_rank: Regular Contributor
timestamp: July 27, 2018, 04:54:23 pm
content: 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...

author: hazzer
author_rank: Regular Contributor
timestamp: July 27, 2018, 10:20:32 pm
content: Worked great, awesome to have the cal data backed up from my 3457A......hazzer

author: 0xfede
author_rank: Regular Contributor
timestamp: July 28, 2018, 03:48:36 pm
content: Quote from: hazzer on July 27, 2018, 10:20:32 pmHi hazzer,so you succeded in dumping the CAL RAM?Do you mind sharing the content?Thanks in advance,0xfede

author: maxwell3e10
author_rank: Frequent Contributor
timestamp: July 28, 2018, 04:49:30 pm
content: 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.

author: dl1640
author_rank: Regular Contributor
timestamp: July 29, 2018, 03:29:09 am
content: Quoteare 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.

author: 0xfede
author_rank: Regular Contributor
timestamp: July 29, 2018, 08:27:53 am
content: Quote from: dl1640 on July 29, 2018, 03:29:09 amIt 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

author: dl1640
author_rank: Regular Contributor
timestamp: July 30, 2018, 03:22:31 am
content: 0xfedei had trouble by sending "TRIG 4", it returns err.16so 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.

author: sipo75
author_rank: Contributor
timestamp: September 30, 2018, 12:44:23 am
content: I will add my dump. Will the dump work with this ROM version?03457-88804 REV 4 WYLE LABS

author: 0xfede
author_rank: Regular Contributor
timestamp: September 30, 2018, 07:52:37 pm
content: 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 410 FOR I = 20480 TO 22528 STEP 220 PEEK I30 NEXT IBest,0xfedeQuote from: sipo75 on September 30, 2018, 12:44:23 am

author: sipo75
author_rank: Contributor
timestamp: October 01, 2018, 10:33:17 pm
content: Does this dump look plausible?

author: Grippy
author_rank: Newbie
timestamp: December 06, 2018, 09:06:57 pm
content: 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:#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 matchimport visaimport timeimport hashlibrm = visa.ResourceManager()inst = rm.open_resource('GPIB0::22::INSTR')inst.write('TRIG 4') #Freeze instrument so we can read from itdef 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 newertry: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("'").partition("'") + '\n' #Split weird formatting and add a newlinef.write(str(x) + ": " + str(int(float(string_data))) + "\n") #Write it's float equivalent to diskprint(str(string_data) + " Or Decimal: " + str(int(float(string_data)))) #Print what was writtenpassexcept:print("Couldn't read after " + the_str)f.write("THIS IS BROKEN")f.close()f.close()#Function to Get MD5 Sumdef 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 isprint((str(inst.read_bytes(9)).partition("'").partition("'").partition('A') + " Detected")) #Print instrument responsestart_adress = input("Memory Start Adress (64 or 20480 reccomended): ")end_adress = input("End Adress(512 or 22528 recommended, 65535 max): ")#First Checksumfname_1 = "3457_DUMP_" + str(int(time.time())) + ".txt"f = open(fname_1, "w")peek_memory(f);checksum1 = md5(fname_1);#Second Checksumfname_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...

author: ipqobk
author_rank: Contributor
timestamp: February 05, 2019, 08:16:34 pm
content: 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

author: ipqobk
author_rank: Contributor
timestamp: February 08, 2019, 10:37:33 am
content: 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

author: ipqobk
author_rank: Contributor
timestamp: February 08, 2019, 10:52:51 am
content: This is the comparison of the three dumps with win10 / 32bit

author: ipqobk
author_rank: Contributor
timestamp: February 08, 2019, 11:14:24 am
content: 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.

author: bingo600
author_rank: Super Contributor
timestamp: February 10, 2019, 04:46:16 pm
content: Quote from: ipqobk on February 08, 2019, 11:14:24 amAny pointers to nightpanda's work ?/Bingo

author: ipqobk
author_rank: Contributor
timestamp: February 11, 2019, 10:26:45 am
content: 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.2Paolo

author: pomonabill221
author_rank: Frequent Contributor
timestamp: March 10, 2019, 02:45:50 am
content: 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?

author: tppc
author_rank: Regular Contributor
timestamp: January 26, 2020, 10:47:40 am
content: Quote from: ipqobk on February 08, 2019, 10:37:33 amHi 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

author: tppc
author_rank: Regular Contributor
timestamp: February 08, 2020, 08:14:53 pm
content: Hi there,The Memory Dumper works fine.You just need to know that after pluging the GPIB - USB adapter, you need to configure it withPrologix.exefrom the KE5FX GPIB toolkithttp://www.ke5fx.com/gpib/readme.htmAfter doing so,0xfede's Cal RAM utility works great!THANK YOU.Regards

author: Tryer
author_rank: Contributor
timestamp: May 20, 2020, 04:36:12 pm
content: 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.BI must say that i could not find a schematic for that version.The one i found, is for Rev. AI 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 againVos can exsisto rabidus per totum annum, after your discovery...

author: 0xfede
author_rank: Regular Contributor
timestamp: May 21, 2020, 12:25:26 pm
content: 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.μηδὲν ἄγαν.0xfedeQuote from: Tryer on May 20, 2020, 04:36:12 pm

author: Tryer
author_rank: Contributor
timestamp: May 21, 2020, 03:18:35 pm
content: 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 makesthe 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.457V20.Feb 20 3.474V01.Apr 20 3.500V25.Apr 20 3.504V18.Mai 20 3.508VLatest at 5V i will replace it.Greetings, TryerΕΝ ΟΙΔΑ ΟΤΙ ΟΥΔΕΝ ΟΙΔΑ

author: 0xfede
author_rank: Regular Contributor
timestamp: May 21, 2020, 05:46:34 pm
content: 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Ἄκουε τοῦ τὰ τέσσαρα ὦτα ἔχοντος

author: Nuno_pt
author_rank: Frequent Contributor
timestamp: May 21, 2020, 05:55:08 pm
content: 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

author: Tryer
author_rank: Contributor
timestamp: May 22, 2020, 07:53:27 am
content: 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.A8-68A/8-68BI hope the last line 8-68B means Rev. 8-68BI will write a small routine (Borland C)like:for all calram bytes{do{POKE 48,00 // may be 2-3 times that linepoke adrs,byte1poke adrs+1,byte2} while peek(adrs) not as just writtenadrs = 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"

author: Tryer
author_rank: Contributor
timestamp: May 22, 2020, 03:12:28 pm
content: @Nuno_ptAny 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?

author: Nuno_pt
author_rank: Frequent Contributor
timestamp: May 22, 2020, 03:57:57 pm
content: @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.

author: wiesl
author_rank: Contributor
timestamp: May 22, 2020, 07:04:43 pm
content: Quote from: ipqobk on February 05, 2019, 08:16:34 pmHello,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#: 2703A06XXXBattery voltage of Saft Lithium LX1634 (looks original): 3.0328VEPROM: 03457-88810, D/C 8825Main Controller: 03457-66511 Rev A 88809FInput Signal Conditioning, A/D Converter, Inguard Controller: 03457-66502 Rev C 88809FAC Converter: 03457-66503 Rev B 88809FReference voltage board: 03456-66525 Rev B 88809FKeyboard board: 03457-66505 8809F Rev AGuess 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

author: Tryer
author_rank: Contributor
timestamp: May 23, 2020, 07:25:00 am
content: 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)

author: wiesl
author_rank: Contributor
timestamp: May 23, 2020, 09:36:06 am
content: Quote from: Tryer on May 23, 2020, 07:25:00 amNo, cover and screws are there. Was too late yesterday, didn't think about thatYes, expecting exactly 448 but get more.Wiesl

author: wiesl
author_rank: Contributor
timestamp: June 01, 2020, 08:22:35 pm
content: Quote from: Tryer on May 23, 2020, 07:25:00 amCould 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/US4747048Forth interpreter discussed also at:https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg1185473/#msg1185473Wiesl

author: Tryer
author_rank: Contributor
timestamp: June 08, 2020, 03:39:20 pm
content: 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

author: wiesl
author_rank: Contributor
timestamp: June 13, 2020, 12:42:08 pm
content: Quote from: wiesl on June 01, 2020, 08:22:35 pmCould 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~A5Ad 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

author: Wim13
author_rank: Frequent Contributor
timestamp: August 06, 2020, 04:03:49 pm
content: 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 KbyteThe 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 TC5517APLThe unprotected write adresses are different for U511in 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 RAMand 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 Kbyteyou 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.

author: Wim13
author_rank: Frequent Contributor
timestamp: August 09, 2020, 03:06:38 pm
content: 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, U506the Cal Ram 2 kbyte, U511The ROM 8 Kbyte, (TMM2365p) , U503The EPROM 32 Kbyte (AM27256), U502, version 03457-88803If 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.

author: wiesl
author_rank: Contributor
timestamp: March 16, 2021, 02:16:22 pm
content: Which software version does your meter have?

author: Labrat101
author_rank: Unknown
timestamp: May 02, 2021, 09:42:59 pm
content: Hi AllI have also just acquired a fully functional HP3457AAnd 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

author: Labrat101
author_rank: Unknown
timestamp: May 07, 2021, 12:32:52 pm
content: 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 interferewith 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,0Being Not Programming minded at any level .. Hardware I am OK onCan one of you smart guys tell me can I do the cal dump on this NVram as per photo .using the code that0xfedevery 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 ONLYSo 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 DateI 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"

author: Labrat101
author_rank: Unknown
timestamp: May 17, 2021, 10:32:48 pm
content: 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 niceProgram that works out the box even a non software guy understood it .https://www.eevblog.com/forum/metrology/3458a-logging-via-windows-app-revisited/?allit also has a Cal Read which I tried and it dumped the 448 bytes of cal memory with no problemwith 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 .