Author Topic: Dumping and restoring the CAL RAM of an HP3457A  (Read 17168 times)

0 Members and 1 Guest are viewing this topic.

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Dumping and restoring the CAL RAM of an HP3457A
« on: February 04, 2018, 11:40:12 am »
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.
« Last Edit: February 07, 2018, 10:08:27 am by 0xfede »
Semel in anno licet insanire.
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: au
Re: Dumping CAL RAM of a HP3457A
« Reply #1 on: February 04, 2018, 12:05:31 pm »
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.

 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping CAL RAM of a HP3457A
« Reply #2 on: February 04, 2018, 12:22:43 pm »
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?

Semel in anno licet insanire.
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: au
Re: Dumping CAL RAM of a HP3457A
« Reply #3 on: February 04, 2018, 01:31:30 pm »
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.


 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping CAL RAM of a HP3457A
« Reply #4 on: February 04, 2018, 02:07:26 pm »
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
Semel in anno licet insanire.
 

Offline kj7e

  • Frequent Contributor
  • **
  • Posts: 911
  • Country: us
  • Damon Stewart
Re: Dumping CAL RAM of a HP3457A
« Reply #5 on: February 04, 2018, 02:58:32 pm »
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.
 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping CAL RAM of a HP3457A
« Reply #6 on: February 04, 2018, 03:12:39 pm »
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
Semel in anno licet insanire.
 

Offline Magnificent Bastard

  • Regular Contributor
  • *
  • Posts: 139
  • Country: aq
Re: Dumping CAL RAM of a HP3457A
« Reply #7 on: February 04, 2018, 04:00:16 pm »
@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.
« Last Edit: February 04, 2018, 06:18:15 pm by Magnificent Bastard »
 

Offline rigrunner

  • Frequent Contributor
  • **
  • Posts: 261
  • Country: gb
Re: Dumping CAL RAM of a HP3457A
« Reply #8 on: February 04, 2018, 06:51:26 pm »
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/
Internet of Things: A solution desperately trying to find its problem
 
The following users thanked this post: 0xfede, kj7e, Magnificent Bastard

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping CAL RAM of a HP3457A
« Reply #9 on: February 04, 2018, 07:18:07 pm »
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
Semel in anno licet insanire.
 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping CAL RAM of a HP3457A
« Reply #10 on: February 05, 2018, 12:07:38 pm »
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
Semel in anno licet insanire.
 
The following users thanked this post: Magnificent Bastard

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping CAL RAM of a HP3457A
« Reply #11 on: February 06, 2018, 08:10:46 pm »
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
Semel in anno licet insanire.
 
The following users thanked this post: lowimpedance, chickenHeadKnob, shodan@micron, pa3gyf, flittle, VNUTDENYER

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: au
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #12 on: February 07, 2018, 01:10:44 am »
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?
 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #13 on: February 07, 2018, 06:24:34 am »
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
« Last Edit: February 07, 2018, 06:29:43 am by 0xfede »
Semel in anno licet insanire.
 

Offline Magnificent Bastard

  • Regular Contributor
  • *
  • Posts: 139
  • Country: aq
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #14 on: February 07, 2018, 03:06:57 pm »
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   :-+  :clap:
 
The following users thanked this post: mattaw

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #15 on: February 07, 2018, 03:40:39 pm »
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.  :'(
« Last Edit: February 07, 2018, 03:47:42 pm by 0xfede »
Semel in anno licet insanire.
 
The following users thanked this post: hazzer, notfaded1

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #16 on: February 07, 2018, 04:11:54 pm »
(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.
 

Offline Magnificent Bastard

  • Regular Contributor
  • *
  • Posts: 139
  • Country: aq
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #17 on: February 07, 2018, 07:21:50 pm »
(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 ...
 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #18 on: February 08, 2018, 10:44:26 am »
(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?
Semel in anno licet insanire.
 

Offline hazzer

  • Contributor
  • Posts: 27
  • Country: ie
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #19 on: July 21, 2018, 09:11:47 am »
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
 

Offline 0xfedeTopic starter

  • Regular Contributor
  • *
  • Posts: 201
  • Country: it
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #20 on: July 22, 2018, 05:30:19 pm »
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

Semel in anno licet insanire.
 
The following users thanked this post: hazzer, Tryer

Offline maxwell3e10

  • Frequent Contributor
  • **
  • Posts: 869
  • Country: us
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #21 on: July 22, 2018, 07:36:58 pm »
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.
 

Offline dl1640

  • Regular Contributor
  • *
  • Posts: 222
  • Country: cn
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #22 on: July 24, 2018, 12:37:34 pm »
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?
 

Offline hazzer

  • Contributor
  • Posts: 27
  • Country: ie
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #23 on: July 26, 2018, 05:12:01 pm »
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.
 

Offline hazzer

  • Contributor
  • Posts: 27
  • Country: ie
Re: Dumping and restoring the CAL RAM of an HP3457A
« Reply #24 on: July 26, 2018, 05:17:01 pm »
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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf