HP 3478A: How to read/write cal SRAM

[MarkL]

I found a way to read and write the cal SRAM on the 3478A via the GPIB interface.  It's an old question on how to (easily) backup the calibration on these devices, and I'm not aware that anyone has figured it out yet.

I was inspired to look for hidden GPIB commands by this post:

  https://www.eevblog.com/forum/repair/hp-3421a-cal-ram/msg1176864/#msg1176864

(Sorry for my partial cross-post, but I decided this information really needs to be in a 3478A thread where people can find it.)


For those familiar with the 3478A, recall that the cal SRAM is 256 x 4 (NEC UDP5101L or equivalent).

For reading, there's a hidden GPIB command called "W".  The format is as follows:

  W<addr>

Where <addr> is a single byte address to be read from the calibration RAM.  <addr> is in binary, thus allowing access to all 256 locations.

The value returned is the nibble at <addr>, but the value is offset by 0x40 so the result is printable.  For each "W<addr>" command issued, the 3478A will transmit one byte in range of 0x40 to 0x4f ("@" to "O").

I double checked the values returned by "W" with values previously captured via a logic analyzer attached directly to the SRAM.  They match.  A dump of the concatenated bytes returned looks like this:

  0000000: 40 40 40 40 40 49 45 41 4d 43 42 4c 4d 42 40 40  @@@@@IEAMCBLMB@@
  0000010: 40 40 40 41 41 4d 4e 45 41 4d 4c 40 40 40 40 40  @@@AAMNEAML@@@@@
  0000020: 40 41 4d 40 4d 4c 4d 48 49 49 49 49 49 41 41 4e  @AM@MLMHIIIIIAAN
  0000030: 4d 43 4e 4a 44 49 49 49 49 49 49 41 4e 4e 45 4f  MCNJDIIIIIIANNEO
  0000040: 49 48 40 40 40 40 40 40 40 40 40 40 40 40 40 49  IH@@@@@@@@@@@@@I
  0000050: 49 46 48 45 46 41 4f 41 41 4e 4b 44 40 40 40 40  IFHEFAOAANKD@@@@
  0000060: 45 47 40 45 41 4d 43 4d 4d 40 40 40 40 40 47 40  EG@EAMCMM@@@@@G@
  0000070: 45 4c 40 4f 4d 48 40 40 40 40 40 41 40 45 4d 4f  EL@OMH@@@@@A@EMO
  0000080: 4d 4d 40 40 40 40 40 40 40 40 45 4d 43 4f 4d 4b  MM@@@@@@@@EMCOMK
  0000090: 40 40 40 40 40 40 40 45 4d 4c 41 4e 40 40 40 40  @@@@@@@EMLAN@@@@
  00000a0: 40 40 40 40 44 45 45 40 4f 41 40 40 40 40 40 40  @@@@DEE@OA@@@@@@
  00000b0: 40 41 4c 43 4e 4e 41 49 49 49 47 46 42 42 4d 44  @ALCNNAIIIGFBBMD
  00000c0: 41 42 4b 4f 49 49 49 49 47 49 42 4d 4e 45 42 4a  ABKOIIIIGIBMNEBJ
  00000d0: 47 40 40 40 40 40 40 40 40 40 40 40 40 40 49 49  G@@@@@@@@@@@@@II
  00000e0: 46 48 45 46 42 4f 41 43 41 4b 4e 40 40 40 40 40  FHEFBOACAKN@@@@@
  00000f0: 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40  @@@@@@@@@@@@@@@@

The nibble at address 0x00 goes back and forth between 0x40 and 0x4f if the cal switch is enabled.  This is because the firmware writes to this location and then reads it back.  The cal switch enables/disables the write line to the SRAM in hardware, so if the firmware was successful in writing a different value to 0x00 it knows the cal is enabled.

For writing SRAM nibbles, the hidden GPIB command is:

  X<addr><val>

Where <addr> is a one byte binary address and <val> is a one byte value to be written.  Only the lower 4 bits of the value are written to the SRAM.  This allows a raw binary value to be specified, or the printable value that was returned by the W command.

It's probably not a great design that it only takes one erroneous character, X, sent on the GPIB interface to ruin your calibration constants.  Always keep the cal switch off.

In the process of trying to figure out the write command, I managed to trash my SRAM pretty badly.  I was able to fully restore my SRAM to its previous state, so I can vouch that all this works.


It would be nice if someone could write a python or some other multi-platform method that implements the above in a friendly way.  There's a lot 3478A's out there.  It would make battery replacement a lot less stressful if you could back up the SRAM first and then restore it when done.  No more isolated soldering irons, etc.  Or even better, it would be good to make a backup *before* the battery goes dead.

[nfmax]

Just to confirm you mean the addresses are in binary, so a one byte value from 0 to 255, not a string of text like "01010101". Or have I read it wrong?

[MarkL]

Just to confirm you mean the addresses are in binary, so a one byte value from 0 to 255, not a string of text like "01010101". Or have I read it wrong?

Right, a one byte binary value, 0 to 255.  Not a string representing bits or a decimal or anything ASCII.  It also means the GPIB implementation you're using needs to be 8-bit clean for this to work.  Granted, it's not consistent with the documented commands, but I guess they didn't care since it's undocumented and simpler to implement with a single byte.

Example:  Read from address 0x72 is two bytes long: 0x57 0x72

[lowimpedance]

Thanks for the effort you put into this including the restoration of the trashed cal data proving it works.  .
And as you say there are plenty of these meters still in service.

[MarkL]

Thanks for the effort you put into this including the restoration of the trashed cal data proving it works.  .
And as you say there are plenty of these meters still in service.

Of course!  After I discovered I trashed my calibration, I was *really* committed to finding how the write works.

[pigrew]

Excellent.

I just (very quickly) wrote a Windows program to read/write the calibration block. It needs a very recent version of the NI or Keysight VISA libraries. I've tested it with a NI USB GPIB adapter.

The source code and a zip file containing a build are at: https://github.com/pigrew/HP3478Ctrl

MarkL, I very much appreciate that you figured out the commands to use.

-Nathan

[dfrederickson]

Excellent, MarkL.

It seems that the 3478 arranges the cal data differently than the 3468 and 3421.  Those instruments use 16 nibbles to store the constants for each function-range and what appears to be a 4-nibble ECC checksum.

The 3478 stores the cal constants for, by my count, 16 function-ranges.  If your data is rearranged as follows then a pattern appears that would support that many function-ranges.
@
@@@@IEAMCBLMB
@@@@@AAMNEAML
@@@@@@AM@MLMH
IIIIIAANMCNJD
IIIIIIANNEOIH
@@@@@@@@@@@@@
IIFHEFAOAANKD
@@@@EG@EAMCMM
@@@@@G@EL@OMH
@@@@@A@EMOMM@
@@@@@@@EMCOMK
@@@@@@@EMLAN@
@@@@@@@DEE@OA
@@@@@@@ALCNNA
IIIGFBBMDABKO
IIIIGIBMNEBJG
@@@@@@@@@@@@@
IIFHEFBOACAKN
@@@@@@@@@@@@@
@@@@@@@@

The next task is to figure out how the constants are encoded.  I'd like to restore my DMM to at least the factory default parameters.  Figuring out the method of calculating the checksum may be the trickier task.

BTW, just because the CAL RAM is valid doesn't mean the instrument is calibrated as accuracy drifts with time.  If the CAL RAM is corrupt, the instrument will revert to the default parameters.

Dave

[MarkL]

I just (very quickly) wrote a Windows program to read/write the calibration block. It needs a very recent version of the NI or Keysight VISA libraries. I've tested it with a NI USB GPIB adapter.

Thanks for picking up the ball to write something that makes this method accessible for 3478A owners.

I used Perl and bash scripts on linux to do my testing, and they were not written with user-friendliness in mind.

[dfrederickson]

The breakdown of the SRAM makes sense.

But even if you could figure out the encoding and the checksum, how do you know what the factory default values should be?

Hmm, let's see.  The input response is linear and the equation for a line is y=mx+b.  Constants are stored for Zero and Gain, so, from the HP Journal article for the 3468:

Besides ESD, there is also a small chance that an alpha particle or a cosmic ray may alter a single bit of the memory. To protect against this rare occurrence, the two constants for each function and range have parity bits associated with them so that the 3468A's microprocessor can locate singlebit errors and detect double-bit errors. The processor can correct a single-bit error in a calibration constant and the instrument will remain calibrated. If the processor detects more than a single-bit error, the CAL annunciator is displayed and the error bits are set to warn the user that the readings are uncalibrated. When this type of error is detected, the processor uses default values of zero for Y and one for G.

I have a pretty good idea of how many nibbles are used for Zero, Gain, and checksum for the 3468 and 3421.
http://hpmuseum.org/forum/thread-8061-post-71213.html#pid71213
For the 3468 and 3421, calibration values are entered as six digits.  The difference between the entered value and the measured value is stored as Zero and the ratio between the entered value and the measured value is stored as the Gain.  It's not necessary to store all the significant digits.  For example, if the 3 most significant digits for the Zero are always zero, then it's only necessary to save the least significant 3 digits and the sign.  Same is true for the Gain correction factor except the most significant digits will be either 1.00 ... or 0.99 ... so the MSB needs to be saved, too.

Dave

[Armadillo]

There are so many uncertainties with claims as yet to be demonstrated, and for all you know, the undocumented command "W" may be returning an error bytes from Global Variables Iberr or ibsta and yes the logic analyser will be reading the same bytes returned. That, I am afraid cannot be taken as an affirmation of correctness.

In the other post, dfrederickson wrote;

Quote "Now I need to calibrate one parameter at a time and see which data changes, then figure out how the constants and parity/checksum  are encoded. Unfortunately the 3478 responds to the B2 command with the B1 command status. Dave"


unless you know the location of each parameter and the exact representation taking into account any of the endians, example enter 41.2 represented at location X as 0x34, 0x31, 0x2E, 0x32, "yy" checksum, otherwise is doubtful the application and usability of it.

[Armadillo]

http://hpmuseum.org/forum/thread-8061-post-71213.html#pid71213

Now those are interesting investigation. thanks

[dfrederickson]

There are so many uncertainties with claims as yet to be demonstrated, and for all you know, the undocumented command "W" may be returning an error bytes from Global Variables Iberr or ibsta and yes the logic analyser will be reading the same bytes returned. That, I am afraid cannot be taken as an affirmation of correctness.

In the other post, dfrederickson wrote;

Quote "Now I need to calibrate one parameter at a time and see which data changes, then figure out how the constants and parity/checksum  are encoded. Unfortunately the 3478 responds to the B2 command with the B1 command status. Dave"


unless you know the location of each parameter and the exact representation taking into account any of the endians, example enter 41.2 represented at location X as 0x34, 0x31, 0x2E, 0x32, "yy" checksum, otherwise is doubtful the application and usability of it.

I do know the location of each parameter, at least for the 3468 and 3421.  Knowing that there are 5 ranges for DCV, 2 for DCI, 1 each for VAC and ACI, and 7 for resistance I can pretty much figure out which function-range is in each row, above.  Now I just need to figure out the encoding.

Dave

[Armadillo]

I do know the location of each parameter.  Now I just need to figure out the encoding.

Dave

+1; 

[MarkL]

There are so many uncertainties with claims as yet to be demonstrated, and for all you know, the undocumented command "W" may be returning an error bytes from Global Variables Iberr or ibsta and yes the logic analyser will be reading the same bytes returned. That, I am afraid cannot be taken as an affirmation of correctness.

The logic analyzer was attached to the data, address, and control lines of the SRAM (U512) and captured each nibble stored at each address.  How to set up the logic analyzer capture was discussed in a different thread a couple of years ago:

  https://www.eevblog.com/forum/testgear/3478a-cal-ram-readout-idea/msg695908/#msg695908

The SRAM would not be storing iberr or ibsta anyway since the SRAM is read-only during normal operation.  It's only used for calibration data.  The internal SRAM of the 8039 processor (128 bytes) is what's used for volatile storage while the unit is running.

I have no doubt that "W" returns the nibble at each specified address in the SRAM (and that would be the calibration external SRAM U512, to be specific).

Try it for yourself if you don't believe me.  Or try reading the service manual theory section 7-F-60, or look at how the SRAM is controlled in the schematic.  Verification is always encouraged.

[MarkL]

The breakdown of the SRAM makes sense.

But even if you could figure out the encoding and the checksum, how do you know what the factory default values should be?

Hmm, let's see.  The input response is linear and the equation for a line is y=mx+b.  Constants are stored for Zero and Gain, so, from the HP Journal article for the 3468:
...

Ok, read your thread at hpmuseum.

One way to tackle this would be to figure out the ECC algorithm so you can poke values into the cal locations to see how they affect readings.  (Maybe that's what you had in mind; sorry if I'm stating the obvious...)

I'm not familiar with the 3468A or 3421A, but on the 3478A it would be possible to use a logic analyzer to watch the fetch and execution of instructions as it computed the ECC.

It should be possible to do a calibration and trigger on a write to any of the associated addresses in the cal SRAM.  I'll take a guess that the firmware will write the new cal nibbles, compute the ECC by perhaps re-reading those nibbles, and then write the new ECC, in that order.  If true, it's an easy way to bracket the code you want.


Well, and then there's always the brute force method.  If you're right that there's only 16 bits of ECC, how long will it take to write and test all the possible ECC values (or half, on average)?  No finesse points for that approach.

[dfrederickson]

Well, and then there's always the brute force method.  If you're right that there's only 16 bits of ECC, how long will it take to write and test all the possible ECC values (or half, on average)?

Hi MarkL,

I don't know, but the Infinite Monkeys Method worked before.   The 3468 is basically an HP-IL version of the 3478, minus a few extra ranges and rear terminals.  The 3421 is a data acquisition instrument that employs a 5.5digit DMM, similar to the 3468 and 3478, but with no front panel controls.  The 3468 and 3421 are highlighted in the Feb 83 issue of the HP Journal and the 3478 got an honorable mention.

True, it would be easy to write a program that sequentially tried all the different checksums until a status error was not reported.  I'll think I'll wait until someone like Sailor simply figures out the algorithm.  In the mean time I can load parameters from another 3468 and clear the error.  For now that should be accurate enough for what I'm doing.

Regards, Dave

[biot]

It would be nice if someone could write a python or some other multi-platform method that implements the above in a friendly way.  There's a lot 3478A's out there.  It would make battery replacement a lot less stressful if you could back up the SRAM first and then restore it when done.  No more isolated soldering irons, etc.  Or even better, it would be good to make a backup *before* the battery goes dead.

I'm attaching a little Python script that pulls the SRAM values out and drops them to stdout. Use like this:

python cal-3478a devicename > mycal

This depends on a properly working linux-gpib setup, and devicename must be a properly configured device in /etc/gpib.conf. No multi-platform GPIB out there, as far as I know.

Thanks so much for working this out -- would hate for my 3478A to die on me. At least now I have a backup! The battery seems to be doing OK, so perhaps I don't need to replace it yet?

[MarkL]

It would be nice if someone could write a python or some other multi-platform method that implements the above in a friendly way.  There's a lot 3478A's out there.  It would make battery replacement a lot less stressful if you could back up the SRAM first and then restore it when done.  No more isolated soldering irons, etc.  Or even better, it would be good to make a backup *before* the battery goes dead.

I'm attaching a little Python script that pulls the SRAM values out and drops them to stdout. Use like this:

python cal-3478a devicename > mycal

This depends on a properly working linux-gpib setup, and devicename must be a properly configured device in /etc/gpib.conf. No multi-platform GPIB out there, as far as I know.

Thanks so much for working this out -- would hate for my 3478A to die on me. At least now I have a backup! The battery seems to be doing OK, so perhaps I don't need to replace it yet?

The python script works for me and the data matches my clunky scripts - thanks!

I haven't replaced my battery yet and it's now 34 years old.  As long as you have a backup, my feeling is not to worry about it.  If one day you turn on your meter and the battery is dead, you can reload the calibration constants and still use the meter while waiting for a new battery.

Of course it's then time to write the SRAM writer script, or even better write it ahead of time.  If you want to PM me a test version I'll try it - I'm not afraid if it takes a couple of spins to get it right and it ruins my constants.  Once right you can post it.

[bingo600]

@MarkL et all

Now we "just" need to reveal the HP3457's secrets      

PHK did the 3458A , and you did the 3478A
Who's doing the 3457A

/Bingo

[MarkL]

@MarkL et all

Now we "just" need to reveal the HP3457's secrets      

PHK did the 3458A , and you did the 3478A
Who's doing the 3457A

/Bingo

Sounds like a fun challenge, but unfortunately I don't have a 3457A.

I did look at the ROM image that's available on KO4BB with "strings" and "xxd".  It looks like there's a ROM monitor that can be accessed somehow.  That might provide a path to read/write the NVRAM (U511).

There's also some occurrences of the words PEEK and POKE in the same area as other GPIB commands.  That looks promising but they might need to be enabled first.


I doubt it will happen, but if anyone wants to lend me a 3457A for a few weeks I'll give it a shot.  I already have a 3456A, so I don't have a good excuse to buy one myself (not to mention making space for another gigantic DMM).

[biot]

I did look at the ROM image that's available on KO4BB with "strings" and "xxd".  It looks like there's a ROM monitor that can be accessed somehow.  That might provide a path to read/write the NVRAM (U511).

Looks like a Forth interpreter in there! Unfortunately I don't have a 3457A either.

However this might be an interesting avenue to figure out the checksum algorithm -- disassemble the 3478A's ROM.

[ramon]

Thank you so much to MarkL for this information and to biot for his python script.

I recently bought a cheap 3478a and the first thing I have done is a backup of the calibration RAM using GPIB.

This is the output in case someone is still working on how to find the checksum algorithm and wants to compare (I already tried to compare my calibration data with data from MarkL and Pigrew meters)

0000000: 4f 40 40 40 46 41 41 42 41 4f 4f 40 4d 46 40 40  O@@@FAABAOO@MF@@
0000010: 40 40 45 49 42 41 40 43 45 4e 46 40 40 40 40 40  @@EIBA@CENF@@@@@
0000020: 46 42 41 40 4e 4e 4d 4a 49 49 49 49 49 44 42 41  FBA@NNMJIIIIIDBA
0000030: 4c 4c 40 4b 43 49 49 49 49 49 49 42 40 45 4f 44  LL@KCIIIIIIB@EOD
0000040: 4a 4f 40 40 40 40 40 40 40 40 40 40 40 4f 4f 49  JO@@@@@@@@@@@OOI
0000050: 49 49 45 49 45 42 4d 45 41 4e 4a 4e 49 49 49 49  IIEIEBMEANJNIIII
0000060: 46 48 41 4c 42 4e 42 4a 4e 49 49 49 49 49 46 41  FHALBNBJNIIIIIFA
0000070: 4c 43 4e 45 4a 49 40 40 40 40 40 40 41 4c 42 42  LCNEJI@@@@@@ALBB
0000080: 45 4e 49 40 40 40 40 40 40 41 4c 40 4f 4d 4d 46  ENI@@@@@@AL@OMMF
0000090: 49 49 49 49 49 49 41 4c 41 40 4f 4a 4c 49 49 49  IIIIIIALA@OJLIII
00000a0: 49 49 49 41 4c 40 43 43 4b 46 49 49 49 49 49 49  IIIAL@CCKFIIIIII
00000b0: 40 45 43 45 45 4b 47 40 40 40 44 43 49 43 42 4c  @ECEEKG@@@DCICBL
00000c0: 43 40 4d 4b 40 40 40 40 44 44 43 42 4d 45 4e 4d  C@MK@@@@DDCBMENM
00000d0: 42 40 40 40 40 40 40 40 40 40 40 40 4f 4f 49 49  B@@@@@@@@@@@OOII
00000e0: 49 45 49 45 43 4e 42 4e 44 4a 4c 40 40 40 40 40  IEIECNBNDJL@@@@@
00000f0: 40 40 40 40 40 40 4f 4f 40 40 40 40 40 40 40 40  @@@@@@OO@@@@@@@@

Also python script to convert the code received from GPIB into actual RAM data (each byte substracted by 64 or 40 hex):

Code: [Select]

#!/usr/bin/python
from functools import partial
import sys

with open(sys.argv[1], 'r') if len(sys.argv) > 1 else sys.stdin as file:
    for byte in iter(partial(file.read, 1), b''):
        sys.stdout.write(chr(ord(byte)-64))
Can be used like this:

  $  xxd -r gpibdata |  script.py | xxd -g 1

Note: I have read again the service manual, and now I understand why the did said 'CAUTION: do not send program codes "W" and/or "X" ... these codes can, under certain conditions, uncalibrate the instrument'

[MarkL]

Note: I have read again the service manual, and now I understand why the did said 'CAUTION: do not send program codes "W" and/or "X" ... these codes can, under certain conditions, uncalibrate the instrument'

Ah, good catch!  I didn't notice that in the manual, but it certainly provided a clue.  In my experimentation I never found any form of the "W" command that would write to memory.  Since they mentioned "W" and "X", it wouldn't have killed them to document those commands and, for that matter, similar cal backup commands for a lot of other equipment.  Tektronix is also quite guilty of hiding such useful commands.

I did the subtraction of 0x40 like this:

  tr '\100-\117' '\000-\017' < caldata | xxd -g1

What I like about Linux... always 100 different ways to do the same thing.

[ramon]

Thanks, with 'tr' is much better!

And yes, I also think that they should have provided complete information about those gpib codes. Moreover considering that they didn't put any effort to hide the calibration switch in the front panel.

The calibration procedure needs so many kinds of expensive calibration devices (in AC,DC,ohms, etc...) that it doesn't make any sense to have such easy-to-turn calibration switch in the front panel. How many devices should have been uncalibrated by mistake?. Do they did that on purpose to increase earnings from maintenance services?

Anyway I am very happy with my meter. The schematics are available, and there is a lot of internal information about them.

I downloaded the ROM and tried to simulate the code with one free simulator available at acebus website (8048 version 208). Unfortunately the program only allows to load up to 64KB source code (asm listing) and I cannot fit the whole dissasembled 8K code into the simulator (I removed extra spaces and comments, and I was only able to reduce it to 88K in size).

The 8048 is quite weird: without CMP or SUB instruction, and also with those pages, mb0/mb1 selector, and bit 12 of program counter. I think I will not be able to find how it works. Is there any thread or progress about that? when I use strings on the ROM I cannot get any useful data. I will need to read the schematics more in detail.

[MarkL]

...
The 8048 is quite weird: without CMP or SUB instruction, and also with those pages, mb0/mb1 selector, and bit 12 of program counter. I think I will not be able to find how it works. Is there any thread or progress about that? when I use strings on the ROM I cannot get any useful data. I will need to read the schematics more in detail.

What are you trying to do?

I think it's going to be difficult to simulate operation of the firmware.  It's very dependent on responses from the hardware.  So, you also have to simulate the hardware, which also means simulating the 8039 in the floating section.

If you're trying to discover the CRC/ECC algorithm, I think you're going to need a logic analyzer attached to a running meter as I described previously.

If you're looking for other hidden commands, the ones that aren't accounted for are: A G I J L O P Q U V Y.  The 3478A is a fairly simple machine, so I wouldn't expect anything else hidden of significance.

Some other discussion of 3478A firmware disassembly is here:

  https://www.eevblog.com/forum/testgear/3478a-cal-ram-readout-idea

And there's also this thread on the 3468A, which is very similar in design:

  https://www.eevblog.com/forum/testgear/hp-3468a-in-continual-resetinit/


Yeah, the 8048 is very limited.  The SUB instruction can be done with the following:

  CPL A
  ADD A, REG
  CPL A

(Courtesy of the MCS-48 Microcomputer User's Manual.)