Yes, another 3458A repair and NVRAM replacement to RAMTRON FRAM

[TiN]

The show must go on, right? One of russian-speaking members, TEKTRON done quite extensive study on 3458A of his friend, which needed little bit of repairs and NVRAM love. But opposite to most of us, mere lurkers, he did alternative way and replaced NVRAMs not with just fresh DALLAS/MAXIM chips but with battery-free ferroelectric memory from RAMTRON. I translated the article to English and publishing his work with his permission 

Here's brief worklog. After initial replacement for NVRAMs, and replacement of exploded mains filter, SELF TEST FAILED AC VOS DAC CONVERGENCE:181 emerged.



In HP 3458A Multimeter Assembly Level Repair Manual this error, similar to dozen others have number 204 direct us to assembly A2 (AC Converter 03458-66502). Lot of time was spent on troubleshooting for a root cause, until main amplifier check was done, not limited just to dual JFET Q403, but also to U404 opamp, using DC input signal as reference.



Inverting input had +6.654 VDC, non-inverting input +6.973 VDC. Got it, here’s the problem. Normally functioning circuit with opamp cannot have such huge offset (319 mV!), so clearly opamp or related parts are faulty. These Elantec EL2039 600MHz op-amps are prone to fail in old units, so after replacement meter offset was gone and meter reported no problems!

Easy fix, yea?

FRAM in 3458A:



Works happy for over a year.

TEKTRON also did some tempco testing with his own DIY LTZ1000A reference, and shared his design:



Board was made using laser-printer-toner technology and etching



Comparison victims:



Full article with details as usual hosted on my little site. Worthy read. He also have more to come

[TheSteve]

Seems the Dallas nvram is dead...

[Pipelie]

I just replaced the NVRAMs in my  HP3458A last week,  the total cost of the component is $78 .   
it's necessary to restored original calibration ROM contents before replaced.
after soldered, the NVRAM is dead , all data gone, fortunately,  I have backup.

[Pipelie]

DIP28 FW1808 maybe is the better choice,  but hard to fine a brand new,a genuine part.
I bought five of there used part, just for test.

[quarks]

I also experimented with FRAM, but have not swapped the original Dallas Chips, because they have many years of lifetime left

[bingo600]

Nice mod 

Just ordered the parts   

But i wonder why he says : Do not mod the board before programming the old calram data in the chip ?

If i mod the board first , shouldn't i be able to program it as a DS1220 ?
Then i can "verify" that my mod is functioning.

Or doesn't the programmer "float" the 4 extra pins , he mounted ?

Well i wouldn't mount pins on the last 4 anyway , and prob. do all the wiring/mods on the topside of the adapterboard.

Thanx

/Bingo

[Tektron]

Bingo, because FM16W08 NOT fully compatible with DS1220.
 It has very important difference: all access to Ramtron must be latched by falling edge of CE, not by low level of CE.
I don't know, how work strobing of CE in your programmator, then can't say will it work or not.
In my programmator I can't write Ramtron as Dallas.
It also don't work in HP3457.
But in 3458 it work very well.
You can see all info at p.5 of pdf:   http://www.cypress.com/file/41731
Sorry about my broken english.

[ManateeMafia]

I did something similar with FM1808 for my Datron 1281's replacing the dual CE SRAM with the FRAM. I was able to read it in my GQ-4X programmer.

Photos are at the bottom of the article here https://xdevs.com/fix/d1281/

The meters are currently under test/cal ATM.

[bingo600]

Bingo, because FM16W08 NOT fully compatible with DS1220.
 It has very important difference: all access to Ramtron must be latched by falling edge of CE, not by low level of CE.
I don't know, how work strobing of CE in your programmator, then can't say will it work or not.
In my programmator I can't write Ramtron as Dallas.
It also don't work in HP3457.
But in 3458 it work very well.
You can see all info at p.5 of pdf:   http://www.cypress.com/file/41731
Sorry about my broken english.

@Tektron (Your english is fine enough)
Thank you for the detailed ansver 

I have a TL866A and a GALEP5.

Wonder if the TL866 has a broken programming DS1220 algorithm, afaik writing wasn't even supported a few releases ago.

Edit: Re: 3457A see here (Doesn't it have same MCU as the 3478A ?)
https://www.eevblog.com/forum/projects/3478a-fram-modification/msg1005546/#msg1005546
http://wolfalex.bplaced.net/te/hp3478a/fram/hp3478a_fram.htm

/Bingo

[BravoV]

Wonder if the TL866 has a broken programming DS1220 algorithm, afaik writing wasn't even supported a few releases ago.

Nope, TL866 does not support Ramtron parallel FRAM.

Most Dallas/Maxim BBSRAM (DSxxxx series) only needs the Chip Enable (CE) pin to be enabled only "once" for multiple read/write operations, while the F-RAM needs the CE to be toggled at every address change and latched at CE 's edge.

[bingo600]

Wonder if the TL866 has a broken programming DS1220 algorithm, afaik writing wasn't even supported a few releases ago.

Nope, TL866 does not support Ramtron parallel FRAM.

Most Dallas/Maxim BBSRAM (DSxxxx series) only needs the Chip Enable (CE) pin to be enabled only "once" for multiple read/write operations, while the F-RAM needs the CE to be toggled at every address change and latched at CE 's edge.

Strange 

Tektron says he used a suggests a TL866 to program/write both FRAM types with.

Maybe Tektron can explain what chip he selected on the TL866 when programming, or what programmer he used.



Edit:
Well my GALEP5 can write FRAM's



/Bingo

[Tektron]

@Bingo600, thank you for kind words and 3478+Fram.
I use this programmer:
http://www.phyton.ru/programmers/chipprog-plus.
I didn't wrote exactly model in original of article and the programmer is not well known for english-speaking people, that is why (I think), Ilya wrote TL... in translated version.
I wrote way which tested and WORKS, other ways must be tested 

[TiN]

"Lost in translation". Removed confusing part

Tektron (Your english is fine enough)

It's not much of english problem, it's about getting brave to post. 

You guys might get me into few FRAMs to test myself 

[ap]

Well, one thing is that a programmer is able to make a copy of the calram (write it, applying the correct timing for the active edge of CE), but the other is, what does the 3458A do when trying to update the FRAM during an artifact cal adjustment. Has anybody analyzed that?

[Tektron]

With F-RAM installed in the 3458 I did many times:
CAL 0 - no problem.
CAL 10.0000000 - no problem.
CAL 10.001678E3 - no problem.
ACAL DCV - no problem.
ACAL ALL - no problem.
Change CAL String - no problem.

I did it in December 2015 and repeated in January 2017 (both times with F-RAM installed) - no problem.

[quarks]

My test so far worked without any issues for U121 and U122 with DS1230 to FRAM replacement.

U132 DS1220 is also working, but as discribed above, it is tricky to get the CAL data on the FRAM.
With my Batronix programmer I can write directly to the FRAM, either with SOIC ZIF programming adapter or with the SOIC-to-DIP28 adapterboard (before the DS1220 PIN modifications).
After the modifications, I cannot write to the FRAM in my programmer anymore (which I do not like), but in the 3458A it seems to work.

Nevertheless I still use the original Dallas Chips, because they will most likely work for at least 10 years. But it is good to know, that it can be replaced any time I like.

[Tektron]

Nice job!

But why "ERRor"?

Added later.
It is two ways for using programmer with modified FRAM:
1. Reverse modification, i.e. remove four short and pin 23 of chip connect to pin 23 of adapter (cut it from gnd). Before installing in 3458, return all back.
2. Interchangeable modification. Idea (see pic below) must be tested. I haven't ability to test with 3458.

[quarks]

ERR was because I also tested with empty FRAMs to see the behavior and even this passed selftest.

[Tektron]

ERR was because I also tested with empty FRAMs to see the behavior and even this passed selftest.

Thank you.
If you did not CAL procedure, then you didn't check writing to CalRam, only reading was tested. ACAL writes to CalRam only if enabled, but CAL writes always.

[quarks]

I did CAL 10V to test it with empty FRAM and it worked

Your reversable mod idea looks good, but I think I will next test unmodified SOIC-DIP28 and do all modifications on a separate board which I will stack inbetween. This should give me many options for more experiments.

[TheSteve]

Your separate board can even have a jumper address selection so you can have multiple or different copies of the CAL data.

[Tektron]

Your separate board can even have a jumper address selection so you can have multiple or different copies of the CAL data.

For 4 different refboards.
 Or for 4 different calibrations. For watching long time drift of A9 and ref resistors. Nice idea.

[bingo600]

We have a lot of skilled people here.

One could hope a PCB designer would offer to make an adapter with some jumper config's that would enable us to.

1: Do & undo the pins for emulating a Dallas , and a normal FRAM.
    So we can read/program the chip as a FRAM, and then jumper it as a Dallas.

2: Maybe do the Chipselects too.

I would expect that quite a few of us in both would be joining a "group order" for such a board, maybe do one for both EU 6 US.

Unfortunately i have Zero PCB layout experience

/Bingo

[quarks]

I have made a little board, it is not nice, but seems to work fine in the 3458A.
For test purposes I again used empty FRAM and did several calibrations (CAL 0, CAL 10, CAL 10k) and ran several self tests. CALNUM was counting up and so far it runs without any problems. 
So when you need to CAL all new, because CAL NVRAM data is lost, this should work.

But with original DS1220 data copied to FRAM I found a data difference in address 0 it is 00h instead of 40h as read from DS1220 and this seems to cause ERRSTR 110 "CALIBRATION REQUIRED -- SCAL" in the 3458A. 
So far I was not able to write 40h to address 0.
Did anyone else have the same issue?

[bingo600]

I have made a little board, it is not nice, but seems to work fine in the 3458A.
For test purposes I again used empty FRAM and did several calibrations (CAL 0, CAL 10, CAL 10k) and ran several self tests. CALNUM was counting up and so far it runs without any problems. 
So when you need to CAL all new, because CAL NVRAM data is lost, this should work.

But with original DS1220 data copied to FRAM I found a data difference in address 0 it is 00h instead of 40h as read from DS1220 and this seems to cause ERRSTR 110 "CALIBRATION REQUIRED -- SCAL" in the 3458A. 
So far I was not able to write 40h to address 0.
Did anyone else have the same issue?

Did the programmer verify it w. 40h , or give a verify err ?

I haven't gotten my devices yet (They're "china time" way) , so 4w+ time i guess.
When i get them i can try the Galep5 , but i'd expect Batronix to work equally well ..
Actually maybe even better, as it seems like the Galep5 doesn't get device updates anymore.

/Bingo