3458A How Old is to old for Battery Backed Memory? - Page 1
Forum section: electronics / general

author: beanflying
author_rank: Super Contributor
timestamp: March 15, 2025, 01:44:06 am
content: Finally getting around to some Space and the very much Harder part some Time to look at the 3458A I scored a FOUR years agoLike most of us I don't need it and my two Calibrated 6 1/2 digit meters are more than I require.It had a Cal 110 Error so I had assumed it was going to need a full memory fix and a dirty Cal by me and the wall of bits I have or a $$ trip to Keysight so it went on the shelf. The meter as far as I can find was never Calibrated and given how clean it is inside and still on its 1997 Memory never used or if it was very sparinglyBefore pulling boards out to remove memory and add sockets etc I loaded up IanJ's WinGPIB software and actually got a dump of the Cal memory which I thought was curious but was it garbled or trash?Found in some searching of the Xdevs site the 3458A/KE5FX dump software and managed to get what looks like something resembling data (copy of the text version below).So on that same pagehttps://xdevs.com/article/hp3458a_gpib/#manualthere is also the Query strings for the Cal Constants which also gave back sensible looking numbers (again below). Still cant get connection expert to recognize the 3458A but it still has the 1997 Firmware on it which might be the problem?Can someone more familiar with the 3458A take a look at the dump and see if you think it is complete and valid? If so then any idea what might be causing the 110 error (destructive overloads?) or does is simply need a Cal to clear it when the new memory goes in or is the error just related to the likely dead or near dead battery?Also thoughts on upgrading the Firmware, what would I gain?TIA

author: aronake
author_rank: Frequent Contributor
timestamp: March 15, 2025, 06:06:44 am
content: Do you have a error that say destructive overload? Or Error 110 - Calibration required? Any other errors? Push error button again to see these. And have you done te full selftest (or only the power on self test)? If not, may be a good start to do that and see if any more errors show up

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 15, 2025, 07:57:47 am
content: Here's a python script I wrote that will download the cal values as actual numbers (same as shown when using the front panel) via GPIB.Pull the values out and see if they are reasonable. Then I'd let it warm up for a good few hours, run a full self test and then an ACAL and pull the values out again to compare.

author: beanflying
author_rank: Super Contributor
timestamp: March 15, 2025, 08:06:09 am
content: Quote from: aronake on March 15, 2025, 06:06:44 amI did scroll the errors and only the 110 comes up on startup always. I seem to remember reading about resetting the destructive overloads during a Cal on Xdevs (need to go check again)Very occasionally on a full test I had seen 204 (Flatness DAC) and 202 (Slave Test) seems common but still not always. Without talking a serious look I haven't tried tracking them down for an actual cause or solution.The Cal in particular if it can be salvaged and Memory seemed like a good first thing to do.

author: Kleinstein
author_rank: Super Contributor
timestamp: March 15, 2025, 08:35:22 am
content: The critical SRAM is the small one with the calibration constants. This looks like it is from 1997 and thus time to replace it. How long the batteries actually last can vary with temperature, use and luck. Chances are the CAL data are still there - even if old they can be still valuable - even if just to see how much the meter drifted over the last 28 years.As the very least one should save the data to the PC, so one could restore them if needed. AFAIK there are scripts around to download the data via GPIB. The main point are the real calibration data, not the ACAL values. Having a backup of the CAL data is a good idea even with a new battery or FRAM replacement, just in case.The other 2 larger SRAM are not that critical. One would only loose things like user defined short cuts and previous settings. So if these run out, nothing really valuable is lost.

author: picburner
author_rank: Frequent Contributor
timestamp: March 15, 2025, 09:17:27 am
content: One of my two 3458A purchased time ago had also errors 110 and 202, but in my instrument the error 202 was persistent.Finally it turned out to be the ADC A3 board with the usual faulty U180.I hope this is not your case because it is quite an expensive repair.There were also other small faults but they were just trifles in comparison.

author: IanJ
author_rank: Unknown
timestamp: March 15, 2025, 10:00:54 am
content: Quote from: beanflying on March 15, 2025, 01:44:06 amCan you post the file WinGPIB produced so I can take a look?The files are not text readable if thats what you were looking for.Here's a screenshot of the top of the file in HxD hex editor so you can see the hex and ascii equiv. Yours should look somewhat similar.Ian.

author: beanflying
author_rank: Super Contributor
timestamp: March 15, 2025, 10:30:58 am
content: Quote from: IanJ on March 15, 2025, 10:00:54 amTwo copies taken just in case (extension changed to txt so they post). The decoded version in the first post was from the Xdevs Windoze software and is legible.Any thoughts about if you can use the bigger FM18W08-SG-ND for the Cal Ram? I know it is way to big but I ordered a couple of spares.

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 15, 2025, 12:00:58 pm
content: Here's a link to a video I just made about putting FRAM's into a 3458A.youtu.be/uNbI3SUZ7oII have some spare PCB's I can throw in an envelope and send to you for a couple bucks shipping if you need.

author: beanflying
author_rank: Super Contributor
timestamp: March 15, 2025, 12:10:13 pm
content: Quote from: TERRA Operative on March 15, 2025, 12:00:58 pmNot sure if to fully blame/thank you or a little of IanJ as well for this getting on the bench in the last weekYouTube actually fed me your Video out of the blue so the boards left heading for me a few days ago but thanks anyway. I hadn't been looking at anything 3458A for a long while so the Algorithm is a strange strange thing.I will load up your Python thing tomorrow for a play too. Feet up with a Scotch time.

author: IanJ
author_rank: Unknown
timestamp: March 15, 2025, 12:36:15 pm
content: Quote from: beanflying on March 15, 2025, 10:30:58 amYour WInGPIB extracted .bin files look ok.The beanflying.CAL.txt in your first post is not a file you can directly program a CalRam IC from. That file has the HEX data but along with it some addition representative data just for info.The purpose of the WinGPIB extract is to produce a file you can save away if ever the need arises you need to directly program the file to a FRAM IC or other non-volatile I memory IC.It's exactly 2k in size, the same size as the original Dallas Ram IC.Here's my video on using FRAM IC's with the 3458A.https://youtu.be/cAA1TCvwhuwIan.

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 15, 2025, 01:02:36 pm
content: I can confirm that the WinGPIB cal data output is the exact same as the data when extracted directly from the NVRAM chip in a programmer.At least it worked for me!

author: aronake
author_rank: Frequent Contributor
timestamp: March 15, 2025, 01:55:44 pm
content: I dont think I heard of a checksum error on the calibration RAM (has anyone?). So it may be that a 3458a deal with just a single bit wrong in the calram by returning calibration required error rather than a checksum error. Its also interesting that you do not get error that ram battery is low. So my guess is that for some reason 1 bit somewhere in the ram has flipped, which results in this calibration error, and that the batteries in the ram still have enough power to keep the memory.With a potentially almost 30 year calibration, I would say it has limited value. The somewhat interesting items in it may be CAL? 2 (7V ref value) and CAL? 1 (40K ohm value). But as you have no idea on how much it has been on over these 30 years, and the drift is likely not linear anyway, that probably have quite limited value too.One way forward may to just calibrate it as good as you can now (10V source and 10K ohm source) and see if that correct the errors.

author: bsdphk
author_rank: Regular Contributor
timestamp: March 15, 2025, 05:02:47 pm
content: The cal data is mostly IEEE-754 64 bit binary floating point numbers with a few integers thrown in here here and there.If you look at the hexdump you will see a lot of 0x40 and 0xbf every 8 bytes, that is the floating point exponent

author: MiDi
author_rank: Frequent Contributor
timestamp: March 15, 2025, 11:46:11 pm
content: If it is just ERROR 110,“CALIBRATION REQUIRED — ACAL”​​, execute ACAL ALL after at least 1h warmup, followed by full self test.Errors 204 (Flatness DAC) and 202 (Slave Test) are concerning, but might be fixed by ACAL or after a couple of days on - if you are lucky.

author: beanflying
author_rank: Super Contributor
timestamp: March 16, 2025, 03:35:12 am
content: Actually dropped something on the inputs seems how it is sort of alive. AC Board is not happy at all which is clearly why the 202 error is happening. As the 3458A is warming up it is settling closer toward 10V which is coming out of my 335D (bang on 10.00000 on the 34461A) so that is in the right ballpark. Ohms Range is close as well.The Error 204 hasn't come up again even after several full tests but 202 every timeWaiting for the memory and boards to turn up now and do some desoldering for sockets to get ready.Also taking a minor risk on what is likely salvage Hitachi memory out of China.

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 16, 2025, 06:52:04 am
content: If you have no luck on the Opt 001 Hitachi memory, I can get NOS chips here in Japan. I got a set of 5x HM62256BLP-10 recently for about 25 bucks or so.

author: beanflying
author_rank: Super Contributor
timestamp: March 28, 2025, 05:27:01 am
content: Must mean it is nearly doneI dropped my current Calram dump onto one of the 16W08's I ordered (should have spare boards and IC's if anyone in Oz wants a set as I ordered spares) with my shiny new T48 programmer then soldered it on the adapter. Plugged back in it recognized that it was set at 2k but otherwise returned garbage data.As others have found the various programmers currently around don't like talking to the 16W08 when installed on the mod board without something like IanJ's extra adapter. I might stich something together in spaghetti as I don't need any other boards done unless I have borked the one I just soldered.Ordered a stack of Caps to replace as per TerraO's thread and also a new IEC filter as my Schaffner one in the unit has a bulge in its pants so likely it is close to releaseLikely at this stage to wait the week for the Caps to arrive then start removing boards as needed to to them and the sockets.

author: MiDi
author_rank: Frequent Contributor
timestamp: March 28, 2025, 09:33:44 am
content: Quote from: beanflying on March 28, 2025, 05:27:01 amMight be useful:https://www.eevblog.com/forum/manufacture/fyi-xgecu-tl866ii-and-t48-cant-program-fm16w08-fram-chips/msg5716707/#msg5716707

author: IanJ
author_rank: Unknown
timestamp: March 28, 2025, 10:48:47 pm
content: A 16W08 on an adaptor board to mimic the original Dallas ram won’t work in a programmer (usually). I haven’t heard of a programmer that can read/write it as a Dallas ram.My 2nd adaptor-adaptor to set the pin assignment back to a 16W08 is the way forward, albeit your programmer will have to have the ability to read/write the first 2k and no more.Ian

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 29, 2025, 02:23:38 am
content: The adapter-adapter to turn it back into a 16W08 won't work with my 16W08-Dallas adapter board as I didn't include the extra header pins needed to break out all pins from the 16W08 chip.So, no overhanging pins on the socket, but no programming with the adapter-adapter...

author: beanflying
author_rank: Super Contributor
timestamp: March 29, 2025, 02:34:36 am
content: Quote from: TERRA Operative on March 29, 2025, 02:23:38 amSo NOW you tell meFun Fabricobbling anyway, not going to win any PCB beauty contest either

author: Smokey
author_rank: Super Contributor
timestamp: March 29, 2025, 03:41:55 am
content: I remember seeing Marco Reps made an FRAM adapter too:https://github.com/marcoreps/Dallas-FRAM-Adapters

author: TERRA Operative
author_rank: Super Contributor
timestamp: March 30, 2025, 08:05:05 am
content: Quote from: beanflying on March 29, 2025, 02:34:36 amIt took me a couple tries to figure out what was up too, I only recently figured it out myself...

author: sarnau
author_rank: Contributor
timestamp: August 13, 2025, 09:00:48 pm
content: I am reverse engineering the firmware of the 3458A and as a first result I have the complete calibration memory documented (https://github.com/sarnau/HP-3458A/blob/main/firmware/dump_calibration_file.py). You should really dump the actual memory and not just use CAL?. The reason for this is that the CAL? results are often calculated and have cross-dependencies. It can probably be reversed, but dumping the whole 2kb is definitely easier.BTW: I have an original CALRAM with a manufacturing date of early 1988. Yes, I will replace it with FRAM (boards are on the way), but it strangely still does work great and it didn't loose any calibration so far.

author: TERRA Operative
author_rank: Super Contributor
timestamp: August 13, 2025, 11:58:41 pm
content: If you could find a way to load the cal data back into the 3458A using GPIB, you would make a lot of people happy!There's some sort of security restriction, so while you can easily read the data out, writing it back via the GPIB bus is currently not possible (but I suspect there may be some undocumented commands or a secret handshake or something to upload the cal data)..

author: aronake
author_rank: Frequent Contributor
timestamp: August 14, 2025, 02:07:01 pm
content: Quote from: sarnau on August 13, 2025, 09:00:48 pmI didnt get the link to work. Was the content removed? Im much interested. If you dont want to share widely, could you PM new link to content?

author: picburner
author_rank: Frequent Contributor
timestamp: August 15, 2025, 06:21:59 am
content: It must have been a temporary glitch. The link is working now.

author: sarnau
author_rank: Contributor
timestamp: August 18, 2025, 09:13:01 pm
content: I forgot to make this repo public… Fixed. I am currently adding new work pretty much daily. Today I fixed the schematics in the CLIP pdf (Sheet 2/2 for the Outguard Controller Board was missing a bunch of wires and infos about the chips) - it was copied from larger sheets at some point into a PDF and sadly right through the schematics was a page break.

author: sarnau
author_rank: Contributor
timestamp: August 18, 2025, 09:22:48 pm
content: There are many secret commands, but I do not think there is one for writing the CALRAM.The main issue is that write access to the CALRAM is protected via a circuit. You can see that in the schematics. It needs to be unlocked for write-access and – it seems (I haven't really looked into it) – it is locked automatically via a hardware timer after about 32ms. A simple hardware work-around might be to use connector JM132 (which you could move to write-protect the CALRAM in hardware): remove the jumper and tie the center pin to e.g. U908.10 (which is WRITE-). That way the CALRAM should behave like normal RAM and be writeable via the GPIB command. After writing to it, you can undo this patch wire and reinstall the jumper.BTW: I have commented the 2kb of CALRAM, in case somebody is interested, what is actually in it.

author: bsdphk
author_rank: Regular Contributor
timestamp: August 19, 2025, 09:54:02 am
content: There is no command for writing CALRAM, documented or otherwise.There is a bit of circuitry which prevents writing to the CALRAM unless a particular song&dance has been performed from "protected" CPU mode.The only way I know how to do that, is to define an array, download machine code into it, and execute it.But the functions which perform the song and dance are at different locations in the various firmware versions, so I have never felt comfortable sharing code.

author: sarnau
author_rank: Contributor
timestamp: August 19, 2025, 06:12:51 pm
content: Agreed, but – I haven't tested it – shouldn't stopping all IRQs and writing to $B0000 (CREN-) give write access for ~32ms? The whole IPL 7, etc. seems just additional validation in code.

author: bsdphk
author_rank: Regular Contributor
timestamp: August 20, 2025, 07:43:21 pm
content: You cannot do any of that from "user-mode" code.But there's nothing hard about calling the functions to do the song and dance, it's just a couple of function calls before and after.

author: sarnau
author_rank: Contributor
timestamp: August 20, 2025, 07:55:26 pm
content: I looked at the schematics: it seems more complicated: block IRQs, trigger an IPL7, there have a small delay (defined by another hardware timer via U135) and trigger lifting the write-protection. Check if it was successful, if so write the byte/word/etc and the ~32ms timer (U131) will eventually kick back in to protect the CALRAM again. The code itself also uses some magic variables, but this is just in software.

author: sarnau
author_rank: Contributor
timestamp: August 20, 2025, 08:05:13 pm
content: I think the easiest is to simply check for REV9, which hasn't been updated in forever and is the last version, and the jump directly into the ROM code for writing words. Up to 80 can be written – CALSTR is 80 bytes, maybe more can be written in 30ms. I've done something similar to convert an HP 8711C to an HP 8712C by using the TFTP update to push a small payload to patch a single bit in the flash.

author: bsdphk
author_rank: Regular Contributor
timestamp: August 20, 2025, 08:14:12 pm
content: I got my HP3458 one and half decade ago, and since schematics were not available I never spent time figuring out what the hardware did.I reverse engineered the firmware, found out how to read out the contents of the CALRAM, and programmed the new Dallas with my EPROM programmer before plugging it into the socket I added.Later, I think around 2011, I published how to read the CALRAM, so that other people could make backup-copies too.Later again, somebody in a really sticky situation contacted me, and I worked out the download array method for him, but I was never comfortable releasing it in public.

author: sarnau
author_rank: Contributor
timestamp: August 20, 2025, 08:21:20 pm
content: You were way ahead of me. I am documenting the hardware and firmware on Github:https://github.com/sarnau/HP-3458A.

author: bsdphk
author_rank: Regular Contributor
timestamp: August 20, 2025, 08:39:56 pm
content: Back then HP was still decent company which I still respected, so I only shared my RE-efforts on discontinued products.(Here:https://github.com/bsdphk/PyReveng3/tree/master/examples)HP is different now and Ghidra is available for everybody who care to download it, so that probably sounds a bit old-fashioned :-)Another reason I held back a bit, is that there are a couple of magic counters in the CALRAM, which document instances of abuse, and I did not want to give unscrupulous eBay merchants a way to "run the odometer backwards".You have probably found those already yourself:################################################################ Undocumented CAL? queries# CAL? -1 21249=NUM_SAMPLES# CAL? -2 861=BURST2# CAL? -3 1149=BURST1# CAL? -4 11=NREADINGS# CAL? -5 2010=SMPL_RATE# CAL? -6 1=SSMP_INC# CAL? -7 3.54147092E-05=PERIOD# CAL 2437 16611, DEFEATS valid 2437# CAL 2941 0, DESTRUCTIVE OVERLOADS valid 2941Have you figured out why the "XYZZY" command exists yet ? :-)PS: If you attempt CALRAM writes, remember to recalculate the checksums.

author: sarnau
author_rank: Contributor
timestamp: August 20, 2025, 08:50:28 pm
content: Yes, the CAL ones are known.xyzzyeven has a wikipedia articlehttps://en.wikipedia.org/wiki/Xyzzy_(computing). There are many more commands – many of them seem for internal testing only.What I've tried to search up/down the internet is any documentation for pSOShttps://en.wikipedia.org/wiki/PSOS_(real-time_operating_system), which is used pretty much in all HP instruments since the 80s, but besides on dutch university exercise there is nothing available anywhere – no headers, not code, nothing. Yes, it was closed source, but this code is abandoned for 25+ years.What I found particularly cool is, that the build-in BASIC actually generates 68000 code. That is pretty neat, but complicated.Ghidra with some tweaking generates decent C-code, which is much easier to read.

author: bsdphk
author_rank: Regular Contributor
timestamp: August 20, 2025, 09:24:54 pm
content: Yeah, PSOS as such seems lost to history, but as far as I can tell it was the precursor to VxWorks, or at least VxWorks took major inspiration from it, so there is a lot of conceptual overlap.And yes, that basic "compiler" was a bit tricky to understand :-)BTW: Does Ghidra spot the C-function being called with too few arguments ?As far as I could tell, it was a harmless error, given the other arguments, but I wonder how Ghidra handles that kind of inconsistency ?

author: sarnau
author_rank: Contributor
timestamp: August 20, 2025, 09:32:33 pm
content: Quote from: bsdphk on August 20, 2025, 09:24:54 pmYes, also some functions where D0 is never set, but written to a trigger register. Ghidra complains, but the hardware doesn't care, because the write-access is the trigger, not the value.