HP 34970A Error 741 Fix

[robert_]

Got a 34970A with Error 741 - Cal data lost: String Data. The DMM surprisingly works and a quick check suggests it does fine, as missing cal data would result in it being way off. However, ignoring E741 doesnt help, the PC software refuses to work and just tells me about E741.
I did find a few posts that end up telling me i would need to replace 2 FRAM ICs and then send the unit in for a complete re-cal. Expensive option. Time to think about it...

Sooo, Cal data is stored in a FRAM 24x04A, one for the base unit and one for the DMM card.
Now, whats "String data"? And Where is it?
Disconnected DMM module -> Error is still there, no change at all. Very good! Theres should be nothing in the base unit that needs to be calibrated, so "String Data" couldnt be too important...
Unsoldered the FRAM (Careful! Its right next to the battery POSITIVE terminal, so remove (and later replace*) the Battery first), and read it out: Readable, not totally blanked. See attached _bad.hex
Now i got another working 34970 (official excuse: check and replace battery...) to read out its FRAM too, see _good.hex
Copied the "good" image to new FRAM and soldered in "bad" 34970: Boots up fine, no error! Reinstalled the DMM, also no further problems. Looks like a success...
It would change the serial number etc (maybe thats what "String data" is?) but who really cares...

Short:
Buy a Cypress FM24C04B-G, program 34970a_good.hex into it (any cheap I2C Tool works, its compatible to standard EEPROM 24c04), replace, done.

[free_electron]

these orignal fram's were made by seiko. And they ALL die.
I've seen at least 20 34970's with dead fram's in  the DMM module.

the problem is that Agilent's code treats these as real ram and constantly rewrites them with number of relay actuations and other stuff. In theory FRAM's have an infinite number of write cycles , but in practice it turned out the seiko process has problems.

you cant replace em with eeprom as fram has no erase cycle and the altium code does not invoke an erase cycle...

[commonswift]

Sorry for using an old topic, but I wonder if the content is exactly the same (except for calibration constants) in the two FRAMs? I've got a 34970 with the familiar symptoms and I got some FM24C04B, is it likely to work to replace both of them using the 34970a_good.hex?

[robert_]

Not really sure, but i did fix a few 34970s and it worked out on all of them.
The FRAM in the mainframe doesnt contain anything too important anyway, just relay cycles on 3 relays, that "string data" that doesnt seem to do anything, and some version info.
The FRAM on the multimeter module (if installed) is a different thing, if it dies your unit needs to go for complete re-cal. However, on most 34970s, the FRAM in the mainframe dies first, probably because that relay counter involves more write cycles.

You can also solder in a blank FRAM and re-initialize it by sending:
:DIAG:POKE 15,0,0
:DIAG:POKE 0,0,0

This would also erase the cal FRAM in the multimeter, so be sure to unplug the multimeter module (if it works) first!

[commonswift]

Ok, thanks a lot for the information! So if I get it right, the two FRAMs are not similar in their content and the hex file you provide in the original post is used for the mainframe FRAM?

Does this sound like a reasonable working plan:
1) Replace the mainframe FRAM with a blank and run the re-init that you describe (Less work than to re-program it...) with DMM unplugged
2) If everything then looks fine (DMM has to be re-enabled I've read?), I should read out the (hopefully complete) image from the DMM old FRAM and copy to a new FM24C04B and replace before the old one dies.

But if the DMM FRAM is corrupt, is it possible to solder in a blank FRAM and recalibrate or does the DMM FRAM have to contain some kind of "basic data structures"? If so, I think I can borrow another (fully working) 34970 and copy the DMM FRAM, but I understand that the calibration data would of course be completely wrong.

[robert_]

What errors do you get at the moment?
741 only means the DMM is fine (but really do copy it right now), if you get any other 74x codes its not as good.
Be careful the FRAM on the dmm board is glued onto the PCB (bottom side, wave soldered), unsolder very carefully or better try reading it in curcuit without unsoldering first. Would be a shame to break a bond wire unsoldering it before its backed up.

If the DMM FRAM is dead, just do the re-init sequence with the DMM plugged in. This results in the thing booting with no error afterwards. Then send it to some cal lab and clearly tell them the RAM has been replaced so they readjust everything without thinking anything is broken because it will be several percent off in any range.

You could also do a manual calibration to some first order with fairly simple equipment (lab psu, some other fairly accurate 5digit+ DMM, a few resistors), if you only use it to measure temperatures its probably good enough. Calibration procedure is described in the service manual thats on the agilent website.

[commonswift]

Oh no - I had the unit stored in my weekend place - was planning to have a look at it next weekend - but today I went there to have a more careful look at the 34970A. When browsing the error log I get 748, 741, 742, 743, 744, 745, 746.... nearly the complete set  .

Well, I assume that means that both FRAMs are more or less blank then. So I just replace both and re-init with DMM attached. I will get the appropriate manuals and try to "calibrate" it reasonably right, I cant do a proper calibration but I can access a freshly calibrated Tek DMM4040 (6½) to use as a kind of reference, that will do. having it calibrated at a lab is outside my playground budget. I got it for $170 (including a working 34901) so I shouldn't complain really.

Btw, looking at the 34901 plugin, is there the same kind of FRAM(?) near the big PLCC socket. Do the plugins suffer from the same problems with failing FRAMs?

[douardda]

Btw, looking at the 34901 plugin, is there the same kind of FRAM(?) near the big PLCC socket. Do the plugins suffer from the same problems with failing FRAMs?

The BOM of the 34901A board lists U150 as a FM24C04 FRAM, so yes, this infamous chip is also present on plugins... Ne reason they won't fail either (they are probably written less than the one on the main board or the DMM, so will probably fail later).

In fact, it looks like there is one FRAM chip on every plugin module.

Guess I'll put a few more of these in my basket...
 
David
 

[douardda]

Just a quick reply to tell  I've successfully changed the FM24C04 FRAM chip of one of my 2 plugin modules (the 34907A).

But a first attempt failed, I believe because the blank memory has to be initialized somehow. However I could not find any magic POKE for this; I've tried the documented POKE to reset the FRAMs of the main unit, but it did not work. So I've dumped the content of the chip I removed into a fresh one.

I've written a small blog post on this:  https://whatever.sdfa3.org/hp-34970a-data-acquisition-unit-part-2.html

David

[julian1]

You can also solder in a blank FRAM and re-initialize it by sending:
:DIAG:POKE 15,0,0
:DIAG:POKE 0,0,0

 However I could not find any magic POKE for this; I've tried the documented POKE to reset the FRAMs of the main unit, but it did not work. So I've dumped the content of the chip I removed into a fresh one.
 

The second argument is the data-width and I think should be 8|16|32 according to other POKE examples. 

So, I think the POKE sequence as written is not quite right.

It would be great if @douardda could clarify if possible.

Google doesn't show anything.

[boffin]

And here I was hoping that Error 741 was an op-amp failure.

[Jwalling]

You can also solder in a blank FRAM and re-initialize it by sending:
:DIAG:POKE 15,0,0
:DIAG:POKE 0,0,0

 However I could not find any magic POKE for this; I've tried the documented POKE to reset the FRAMs of the main unit, but it did not work. So I've dumped the content of the chip I removed into a fresh one.
 

The second argument is the data-width and I think should be 8|16|32 according to other POKE examples. 

So, I think the POKE sequence as written is not quite right.

It would be great if @douardda could clarify if possible.

Google doesn't show anything.

I did this a month ago or so after replacing both FRAMs, and it worked for me.
Did you follow this procedure?
https://community.keysight.com/servlet/JiveServlet/download/63858-1-5176/Error%20740%20Series%20for%20fix%2034970A.doc

Step 10 may be important.

Jay

[julian1]

 

I did this a month ago or so after replacing both FRAMs, and it worked for me.
Did you follow this procedure?
https://community.keysight.com/servlet/JiveServlet/download/63858-1-5176/Error%20740%20Series%20for%20fix%2034970A.doc

Step 10 may be important.

Jay

Thanks, that's good confirmation on the POKE procedure.