Electronics > Repair

HP 3478A: How to read/write cal SRAM

(1/40) > >>

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:

--- Quote from: nfmax on April 03, 2017, 09:07:57 pm ---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?

--- End quote ---
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:

--- Quote from: lowimpedance on April 04, 2017, 12:49:55 am ---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.

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

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod