Electronics > Repair

HP 3478A: How to read/write cal SRAM

<< < (27/41) > >>

bingo600:

--- Quote from: biot on April 09, 2017, 04:07:22 pm ---
--- Quote from: MarkL on April 03, 2017, 02:33:56 pm ---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.

--- End quote ---

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?

--- End quote ---

I needed to grab my HP 3478A calibration constants, as i soon have to change the battery.
I have adapted biot's cal-3478a to python3, used on most newer linux'es.
Script is attached as a zip file, so remember to make it executable after extracting it.
I still don't know why only tar and not tar.gz files are allowed ????

The script makes use of linux-gpib, so make sure it works first.

Edit: The zip contains the fixed version (see post below)

/Bingo


References:

Original cal-3478a (python2) here - Thnx biot
https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg1182436/#msg1182436


Raspberry linux-gpip install guide (I used it on a Raspi3 running Bullseye) - Thnx MiDi
https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/msg2008349/#msg2008349


--- Code: ---root@raspi3:~# sudo dmesg | grep -i -e gpib -e agilent
[   14.478470] usb 1-1.4: Manufacturer: Agilent Technologies, Inc.
[   14.648728] gpib_common: loading out-of-tree module taints kernel.
[   14.661207] Linux-GPIB 4.3.5 Driver
[   14.746457] agilent_82357a_gpib driver loading
[   14.748089] usbcore: registered new interface driver agilent_82357a_gpib
[   14.748122] gpib: registered agilent_82357a interface
[   15.860168] usb 1-1.4: bus 1 dev num 7 attached to gpib minor 0, agilent usb interface 0
[   15.871055] agilent_82357a_attach: attached
[  147.005668] gpib0: exiting autospoll thread
[  147.006044] agilent_82357a_detach: detached
[  147.006246] usb 1-1.4: bus 1 dev num 7 attached to gpib minor 0, agilent usb interface 0
[  147.017505] agilent_82357a_attach: attached
root@raspi3:~#

--- End code ---

bingo600:
Hmm ... That's a bit weird ...

I took two dual sets of backup:

One set with Win10 +
https://mesterhome.com/gpibsw/

One set with a Raspi3 (Bullseye)  + linux-gpib
https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg4722449/#msg4722449

I did a compare , first "pairwise" - they matched  ... Both pairs
Then i compared a Win backup against a linux-gpib backup  .... They only matched the first part of the CalRam ...  :scared:

I prob. did a 3478 poweroff/on between the backups.

Is that CalRam used as "normal ram too ????"

Have attched the 4 images ....

Edit:
The first 128 bytes matches across platforms .. aka  on all 4 files.
The last 128 bytes matches if compared with the "other backup" taken on the same platform.
But NOT if comparing a Win vs Lin backup


Hmmm ...  :palm:  - From first post in this thread

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

So what is returned on that "GPIB Read" ... a Nibble (All 256 counts) or a Byte (HP does some magic , and presents those nibbles as bytes)

FSCK !!! - My first byte in the CalRam was 4f , this means that the guy calibrating my meter back in 15' had left Cal Write enabled ...

It looked like it was "Horisontal" , but it missed a little twist ....  |O



/Bingo

pqass:

--- Quote from: bingo600 on February 25, 2023, 03:57:19 pm ---Is that CalRam used as "normal ram too ????"

--- End quote ---

Not likely since the [ground-referenced] MCU is an Intel 8039 which has 128 bytes of RAM built-in and no ROM (needs external [EP]ROM).
The only external RAM is a 256x4 which is just enough to hold 19 records (of 13 bytes each; with 3 records unused).


--- Quote ---The first 128 bytes matches across platforms .. aka  on all 4 files.
The last 128 bytes matches if compared with the "other backup" taken on the same platform.
But NOT if comparing a Win vs Lin backup

Hmmm ...  :palm:  - From first post in this thread

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

So what is returned on that "GPIB Read" ... a Nibble (All 256 counts) or a Byte (HP does some magic , and presents those nibbles as bytes)

/Bingo

--- End quote ---

I'm not sure what's going on with the RasPi GPIB Read but since the problem appears after byte 127, it could be sign related?
Since the upper nibble doesn't exist on the bus, the MCU may just assign a fixed hex 4 to that so the byte is a valid ASCII (between '@' and 'O').

Well the good news is that the cal data from your Win10+ GPIB pull looks to be good since the CRCs are valid.
CRC=ff means the record is verified.

When I pulled my 3478 cal, I made sure I had valid CRCs before messing with the hardware.


--- Code: ---$ ./verify.sh bingo.cal
000001 40 40 40 44 48 44 42 4f 4c 4c 44 4c 42  >@@@DHDBOLLDLB< 00: raw_offset=000484 raw_gain=2fcc4 offset=+000484 gain=1.018564 crc=ff  30 mV DC
00000e 40 40 40 40 44 45 42 4f 4e 45 4d 4c 45  >@@@@DEBONEMLE< 01: raw_offset=000045 raw_gain=2fe5d offset=+000037 gain=1.018847 crc=ff  300 mV DC
00001b 40 40 40 40 40 44 42 4e 43 45 45 4d 4e  >@@@@@DBNCEEMN< 02: raw_offset=000004 raw_gain=2e355 offset=+000004 gain=1.018355 crc=ff  3 V DC
000028 49 49 49 49 49 46 42 4e 41 40 43 4b 48  >IIIIIFBNA@CKH< 03: raw_offset=999996 raw_gain=2e103 offset=-000004 gain=1.018103 crc=ff  30 V DC
000035 40 40 40 40 40 40 42 4d 45 44 44 4e 43  >@@@@@@BMEDDNC< 04: raw_offset=000000 raw_gain=2d544 offset=+000000 gain=1.017544 crc=ff  300 V DC
000042 40 40 40 40 40 40 40 40 40 40 40 40 40  >@@@@@@@@@@@@@< 05: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=00  <not used>
00004f 49 49 49 43 41 40 41 44 44 4d 4d 4b 4d  >IIICA@ADDMMKM< 06: raw_offset=999310 raw_gain=144dd offset=-000690 gain=1.014367 crc=ff  AC V
00005c 49 49 49 48 43 41 40 45 44 45 43 4c 47  >IIIHCA@EDECLG< 07: raw_offset=999831 raw_gain=05453 offset=-000169 gain=1.005453 crc=ff  30 Ohm 2W/4W
000069 49 49 49 49 48 42 41 4c 4e 40 4e 4a 48  >IIIIHBALN@NJH< 08: raw_offset=999982 raw_gain=1ce0e offset=-000018 gain=1.005798 crc=ff  300 Ohm 2W/4W
000076 49 49 49 49 49 49 40 45 42 41 40 4c 41  >IIIIII@EBA@LA< 09: raw_offset=999999 raw_gain=05210 offset=-000001 gain=1.005210 crc=ff  3 kOhm 2W/4W
000083 49 49 49 49 49 49 40 45 40 43 44 4b 4d  >IIIIII@E@CDKM< 10: raw_offset=999999 raw_gain=05034 offset=-000001 gain=1.005034 crc=ff  30 kOhm 2W/4W
000090 49 49 49 49 49 48 40 45 4f 41 4c 4a 49  >IIIIIH@EOALJI< 11: raw_offset=999998 raw_gain=05f1c offset=-000002 gain=1.004906 crc=ff  300 kOhm 2W/4W
00009d 49 49 49 49 49 48 40 45 4f 45 45 4a 4c  >IIIIIH@EOEEJL< 12: raw_offset=999998 raw_gain=05f55 offset=-000002 gain=1.004955 crc=ff  3 MOhm 2W/4W
0000aa 49 49 49 49 49 48 41 4c 44 41 4c 4a 4c  >IIIIIHALDALJL< 13: raw_offset=999998 raw_gain=1c41c offset=-000002 gain=1.006406 crc=ff  30 MOhm 2W/4W
0000b7 40 40 40 41 44 47 43 4e 4d 42 40 4d 43  >@@@ADGCNMB@MC< 14: raw_offset=000147 raw_gain=3ed20 offset=+000103 gain=1.027720 crc=ff  300 mA DC
0000c4 40 40 40 40 41 45 43 4e 4e 4e 4c 4c 40  >@@@@AECNNNLL@< 15: raw_offset=000015 raw_gain=3eeec offset=+000013 gain=1.027776 crc=ff  3A DC
0000d1 40 40 40 40 40 40 40 40 40 40 40 40 40  >@@@@@@@@@@@@@< 16: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=00  <not used>
0000de 49 49 49 41 45 45 42 44 43 41 43 4c 4c  >IIIAEEBDCACLL< 17: raw_offset=999155 raw_gain=24313 offset=-000845 gain=1.024313 crc=ff  300 mA/3A AC
0000eb 40 40 40 40 40 40 40 40 40 40 40 40 40  >@@@@@@@@@@@@@< 18: raw_offset=000000 raw_gain=00000 offset=+000000 gain=1.000000 crc=00  <not used>
0000f8 40 40 40 40 40 40 40 40 0a              >@@@@@@@@.< 19: <padding>

--- End code ---
See my verify.sh script on post #123 on the previous page.

fenugrec:

--- Quote from: bingo600 on February 25, 2023, 03:57:19 pm ---Is that CalRam used as "normal ram too ????"

--- End quote ---

No. IIRC only the first calram location is "weird"; toggled periodically by the mcu to determine whether it's write protected or not. The rest is cal records.



--- Quote ---Since the upper nibble doesn't exist on the bus, the MCU may just assign a fixed hex 4 to that so the byte is a valid ASCII (between '@' and 'O').

--- End quote ---

That is precisely what the firmware does :
https://github.com/fenugrec/hp3478a_utils/blob/master/ROM_disasm/dc118.d48#L2805


--- Code: --- anl p2,#0xf7 ; 14c3 - 9a f7 .w ; calRAM_CE
mov a,r6 ; 14c5 - fe ~
mov r0,a ; 14c6 - a8 (
movx a,@r0 ; 14c7 - 80 . ; read CAL!
anl a,#0xf ; 14c8 - 53 0f S.
add a,#0x40 ; 14ca - 03 40 .@
--- End code ---

the last 3 lines: replace upper nibble with 0x40. This is why the '@' character appears so often in ascii dumps; 0 + 0x40 = '@'

bingo600:
I found the bug  |O |O

Python3 "in it's infnite visdom" is now applying locale/character encoding Ie UTF-8 to strings.
This messes with string operations. And makes old Python2 string conversion tricks unusable  :--

I am NOT a python guru, so this is the way i had to change it, in order to operate on a "binary array" instead of the strings.


--- Code: ---    #
    # Watch out !!!
    # Python3 is doing "locale/character set" conversion on strings
    # You will be BITTEN, if you use old Python2 strings
    #

    # Force a binary array by creating w. bytearray
    bytesArr = bytearray(b'\x00\x00\x00')

    gpib.timeout(devhdl, gpib.T1s)
    for addr in range(256):
        bytesArr[0] = ord('W')
        bytesArr[1] = addr
        bytesArr[2] = 10  # LF

        # The two below lines will NOT work due to the new locale conversion stuff.
        #cmd = "W" + chr(addr) + '\n'
        #gpib.write(devhdl, cmd)

        gpib.write(devhdl, bytes(bytesArr))   # Convert bytesArr back to bytes, before using it
        val = gpib.read(devhdl, 1)
        sys.stdout.buffer.write(val)

--- End code ---

Edit: I know i could just have changed the addr part of the byte array, but the Raspi even w Python will "run circles" around the HP3478A processor.


Attached is a working Python3 - hp3478a cal readout program - It requires linux-gpib to be functional.

And my readouts on Windows and Raspi

Note:
When i took the Windows CalRam backups, i had hp3478a Calibration enabled  :palm:
This means the first byte contain 0x4f (cal enabled) , instead of 0x40 (cal disabled)

When i took the linux / Raspi CalRam backup using the new python program , i had disabled hp3478a Calibration. Making the first byte 0x40.
That is why Win and linux differs in the first byte.

/Bingo

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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