EEVblog Electronics Community Forum
EEVblog => EEVblog Specific => Topic started by: EEVblog on May 11, 2014, 07:33:13 am
-
Dave checks the Dallas DS1220Y chip in the Prema 6047 7.5 digit multimeter to see if the battery is dead, and if the calibration constants have been lost.
http://datasheets.maximintegrated.com/en/ds/DS1220Y.pdf (http://datasheets.maximintegrated.com/en/ds/DS1220Y.pdf)
ROM is here:
http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN (http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN)
EEVblog #615 - Prema 6047 Multimeter Followup (https://www.youtube.com/watch?v=6VTkWJtny9c#ws)
-
You might consider to whack in an FRAM as a replacement for the DALLAS ZeroPower NV-SRAM
They are available as 8Kx8 versions, like the 6164 SRAMs in JEDEC standard SOIC chip.
The only thing you need is one of those little adapter PCBs for 2K DIL sockets.
Should be available from ebay for a few bucks. I couldn't find one with a quick search right now.
FRAM (former Ramtron, now Cypress) datasheet:
http://www.cypress.com/?rID=76573 (http://www.cypress.com/?rID=76573)
-
You are lucky that the DS1220 was still good.
At my work we once had a dead delay generator that used a Dallas DS5000 microcontroller that uses battery backup NVRAM for the main firmware :palm:
So after al those years being in storage the battery was dead and the firmware got corrupted in such a way that the generator was doing random crap.
Lucky after a week of mailing some big research laboratory's we got the original HEX file to restore it in a brand new DS5000 and got the delay generator working again :)
-
The DALLAS DS1220Y is the same one used in the 3458A.
'quarks' also had a 1989 vintage NVRAM in his instrument, and mine was 14 years old, both still working.
But other 3458A owners reported data loss after 10 years already.
So you should get a new NVRAM.
We have copied the contents of our NVRAMs to fresh ones, they are still available from maxim, or from mouser for a low price.
The new designation is: DS1220AD-150+, around 8$.
As you already have saved the content and are able to write it back, you could check, if the NVRAM actually contains the default calibration constants only.
Maybe somebody before experimented with the loading process, or there had been a checksum error before, and the instrument loaded the default values by itself.
Anyhow, this instrument needs a fresh calibration, so I look forward to a calibration video.
Frank
-
Wouldn't it make more sense to store the constants in the ROM? I'd hate to own one of these, and pull it out of the closet to find out that it bricked itself. (Not that it stopped other manufacturers from doing the whole suicide battery thing... I'm looking at you Capcom.)
-
Wouldn't it make more sense to store the constants in the ROM?
Not from a point of view of the calibration house. That would be a real pain to have an EPROM programmer and and procedure on how to program the data in. No cal lab would want to do that. Front panel and NVRAM is the way to go.
The Prema has some sort of factory calibration built into ROM. Whether that is measured data per unit, or just default values that will get close enough, I don't know.
-
http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN (http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN)
not a firmware (at least the primary one)
all it appears to do is count to fff8 (delay?) and jump to $8035
loc_0:
CLD
loc_1:
LDA #$FF
loc_3:
STA $0003
LDA #$F8
STA $0002
LDA #$C1
STA $0001
LDA #0
STA $0000
LDA #0
STA $0004
TAY
loc_16:
CLC
LDA $0000,Y
ADC $0004
STA $0004
INC $0000
BNE loc_23
INC $0001
loc_23:
LDA $0001
CMP $0003
BNE loc_16
LDA $0000
CMP $0002
BNE loc_16
LDA $0004
STA $FFF9
NOP
JMP $8035
can test code at http://skilldrick.github.io/easy6502 (http://skilldrick.github.io/easy6502)
-
A little tidbit : dallas did NOT invent those battery backed rams. It was actually a Mostek idea , later borged by ST. The 48z02 is a mostek partnumber. St still produces these in the snaphat family.
Dallas modded the idea (went around the patent) by encapsulating the batteries.
The mostek did have removable batteries 237 type like used in hp calculators. The chip had a lid with two screws. Later on st modded the body and made the battery pack removable.
Why not use a cell next to the ram ?
First you need special extreme low power rams. Often there is more leakage on the pcb due to greasy fingerprints and badly washed boards (flux remnants) than what the ram consumes
Second .. Wave soldering batteries is not a good idea. Connectors neither ...
Third. Most engineers in the early days couldnt design a proper write lock circuit that would protect the ram contents during brownouts or powercycles
These chips solve that. They have on board power monitors that cut the write gate. Some of them have an expiration mechanism. You need to write a sequence to a specific address (this doesnt alter the data stored there) to unlock for write. You can then write 2 or four bytes. After which the device relocks writing. There are other mechanisms as well in the really advanced ones. Time lockout, number of writes lockout and more.
Dallas then started adding realtime clocks and st followed .
Now, as far as longevity goes this is a different story.
These devices come out of the factory with the battery disengaged. It is not until you activate them by writing successfully the first time that the battery connects internally. In this deepfreeze mode the shelf life is like 20 years and then they still guarantee another 10 years operational life after that.
For some devices they actually released the sequence to put the device back in freeze mode . Data is lost of course.
-
Dave,
It looked like there wasn't much epoxy over the battery on the bottom of the Dallas chip. Depending on whether the exposed side is positive or negative (it looked like it was the positive side) it shouldn't be difficult to drill a small hole by hand to allow you to probe the battery and measure the voltage. Granted, you can't tell how close the memory is to failing, but it would still be useful information. I recently did this with a DS1230Y with a 0030 date code and found the battery is still at 3V32.
Another interesting experiment would be to install the 6116 chip, restore the original cal constants and see how much the meter has drifted since it left the factory.
There's one thing I didn't understand in the video. You talked about the possibility of the unit writing and then reading the NVRAM during the power-on tests. Since the write line is held high by the keylock, how could it write to the NVRAM? I would expect that the checksum would be written to the memory during the calibration process and then checked on powerup to ensure that the cal constants were valid. Am I missing something?
Ed
-
You talked about the possibility of the unit writing and then reading the NVRAM during the power-on tests. Since the write line is held high by the keylock, how could it write to the NVRAM? I would expect that the checksum would be written to the memory during the calibration process and then checked on powerup to ensure that the cal constants were valid. Am I missing something?
The checksum can only be read during powerup and will be compared to a value stored in the ROM. There is no writing to the NVRAM, if Dave said so he is wrong.
-
Looks like the SRAM data is good, just most likely the reference has finally finished aging after 20 years of doing so. If calibrated now I would guess it will stay stable for a long time, though it probably would be best to just leave it on for a week to see if there is any long term drift.
-
Might it be possible to replace the battery RAM with an EEPROM?
-
Might it be possible to replace the battery RAM with an EEPROM?
Seems you have not read the entire threat :=\
An EEPROM will not work because it needs waiting time after each write, the software would have to be modified :scared:
An FRAM will work though, since it is a RAM with EEPROM features. Data retention time 151 years :-+
Here my original post:
Dave might consider to whack in an FRAM as a replacement for the DALLAS ZeroPower NV-SRAM
They are available as 8Kx8 versions, like the 6164 SRAMs in JEDEC standard SOIC chip.
The only thing you need is one of those little adapter PCBs for 2K DIL sockets.
Should be available from ebay for a few bucks. I couldn't find one with a quick search right now.
FRAM (former Ramtron, now Cypress) datasheet:
http://www.cypress.com/?rID=76573 (http://www.cypress.com/?rID=76573)
Modify message
-
A little tidbit : dallas did NOT invent those battery backed rams. It was actually a Mostek idea , later borged by ST. The 48z02 is a mostek partnumber. St still produces these in the snaphat family.
Dallas modded the idea (went around the patent) by encapsulating the batteries.
The mostek did have removable batteries 237 type like used in hp calculators. The chip had a lid with two screws. Later on st modded the body and made the battery pack removable.
Later Dallas had versions with removable battery packs as well so wave soldering could be used.
Why not use a cell next to the ram ?
First you need special extreme low power rams. Often there is more leakage on the pcb due to greasy fingerprints and badly washed boards (flux remnants) than what the ram consumes
Second .. Wave soldering batteries is not a good idea. Connectors neither ...
Third. Most engineers in the early days couldnt design a proper write lock circuit that would protect the ram contents during brownouts or powercycles
I might accept these reasons if many existing working designs which used a low power SRAM and battery and write protect circuit were not changed to use NVSRAMs. In some cases the existing board was not even changed. I considered altering my 2440 back to the original SRAM plus battery configuration but found a better option.
For some devices they actually released the sequence to put the device back in freeze mode . Data is lost of course.
The data is also lost even while powered externally if the internal battery voltage drops far enough to disable the supervisory circuits.
I prefer EEPROMs.
-
http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN (http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN)
not a firmware (at least the primary one)
all it appears to do is count to fff8 (delay?) and jump to $8035
loc_0:
CLD
loc_1:
LDA #$FF
loc_3:
STA $0003
LDA #$F8
STA $0002
LDA #$C1
STA $0001
LDA #0
STA $0000
LDA #0
STA $0004
TAY
loc_16:
CLC
LDA $0000,Y
ADC $0004
STA $0004
INC $0000
BNE loc_23
INC $0001
loc_23:
LDA $0001
CMP $0003
BNE loc_16
LDA $0000
CMP $0002
BNE loc_16
LDA $0004
STA $FFF9
NOP
JMP $8035
can test code at http://skilldrick.github.io/easy6502 (http://skilldrick.github.io/easy6502)
The 6502 memory map looks vaguely like this (derived from staring at the schematic):
$0000-$1FFF (4864 RAM)
$2000-$3FFF (Dallas RAM; repeated 4 times)
$4000-$6000 (nothing)
$6000-$67FF (6520, 6821 equivalent; 4 addresses repeated $200 times)
$6800-$68FF (68488 GPIB controller; 8 addresses repeated $100 times)
$7000-$77FF (uPD8279 display/keypad controller; 2 addresses repeated $400)
$7800-$7FFF (nothing)
$8000-$FFFF (ROM; the 27C256 Dave has provided)
The 6502 reads the reset vector from $FFFC (little endian), which indicates a start address of $C800. There, in the ROM, you will find more sensible initialization code.
EDIT: I've been looking at the code and considering doing a dis-assembly. Would that be of use to anybody?
-
Might it be possible to replace the battery RAM with an EEPROM?
Seems you have not read the entire threat :=\
Seems you have not tried it. :)
An EEPROM will not work because it needs waiting time after each write, the software would have to be modified :scared:
True enough.
An FRAM will work though, since it is a RAM with EEPROM features. Data retention time 151 years :-+
FRAMs, or at least the ones I have checked, have different strobe requirements which may preclude using them as a drop-in replacements.
"Users who are modifying existing designs to use F-RAM should examine the memory controller for timing compatibility of address and control pins. Each memory access must be qualified with a LOW transition of CE."
Here my original post:
Dave might consider to whack in an FRAM as a replacement for the DALLAS ZeroPower NV-SRAM
They are available as 8Kx8 versions, like the 6164 SRAMs in JEDEC standard SOIC chip.
Modify message
I have used Cypress Semiconductor EEPROM based NVSRAMs as drop-in replacements for 64kx8 Dallas NVSRAMs.
-
Seems you have not tried it. :)
FRAMs, or at least the ones I have checked, have different strobe requirements which may preclude using them as a drop-in replacements.
I have tried it once replacing a 32KB SRAM in a battery backuped music equipment from the early 90s. It worked great.
The MCU used was a Hitachi 63B05 or something like that IIRC.
But I can see what you are on about. The /CE Signal needs strobing every byte, which, depening on the exact design could be a problem.
So the Interface PCB should include an OR gate and an AND gate to let the /CS signal go low only when either /WE or /RE are low.
This needs of course, that the /RE signal strobes low once every read.
-
A replacement of a Dallas DS1220 for a 3458A with F-RAM would be very interesting to see, but unfortunately so far I have not
heard of success.
If anyone has details how to make it work, please share.
-
There's also this option...
(http://i.imgur.com/Lcpt5jm.jpg)
It's a hack but it would work.
Sun workstations used to store their ethernet MAC address in a Dallas chip. If the battery failed, the computer would still power up but the MAC would be just "FF" repeated.
So you can google Sun NVRAM hack and see all sort of pictures of people taking dremel tools to remove the potting to get inside to solder wires.
-
It's a hack but it would work.
Why would you bother?
You can still buy the DS1220
-
Well, the battery must be really marginal, as you'd expect. I just got an Error 8 on the original NVRAM chip, so that's that. Had to re-install the factory cal values from the ROM.
-
It's a hack but it would work.
Why would you bother?
You can still buy the DS1220
Well the people who were doing this are IT guys not electronics guys. You can set the MAC from the console and if there's power to the chip, it will stick.
-
Well, the battery must be really marginal, as you'd expect. I just got an Error 8 on the original NVRAM chip, so that's that. Had to re-install the factory cal values from the ROM.
You didn't save the contents of the original Dallas chip?
-
He probably did. Would be interesting to see the new values in the chip now to compare them.
-
You didn't save the contents of the original Dallas chip?
Hu? The whole video was about doing that.
-
There's also this option...
(http://i.imgur.com/Lcpt5jm.jpg)
It's a hack but it would work.
Sun workstations used to store their ethernet MAC address in a Dallas chip. If the battery failed, the computer would still power up but the MAC would be just "FF" repeated.
So you can google Sun NVRAM hack and see all sort of pictures of people taking dremel tools to remove the potting to get inside to solder wires.
Here is something similar
http://www.walshcomptech.com/ps2/dallasrework.html (http://www.walshcomptech.com/ps2/dallasrework.html)
(https://www.eevblog.com/forum/blog/eevblog-615-prema-6047-multimeter-followup/?action=dlattach;attach=93469;image)
This kind of hack is only reasonable for "just for fun" projects, because you can buy a new chip for a few $, therefore the time you spend for the hack does not pay if you do not have fun with it.
For high value gear I would not use it and keep it original instead.
I would only change/swap from original parts, if it gives a significant improvement.
Like F-RAM suppose to give 150 year data retention without battery.
-
I like Dave's videos immensely, but frankly, this episode was really painful to watch.
The cowboyish attitude, the "let's remove a crucial part of this equipment, it should work without because I say so", the "let's stick inside various pieces of random chips I have laying around ???" (joking) was a grueling experience.
At this point, I'm not even amazed if Dave didn't saved any of the data read from the original chip.
-
http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN (http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN)
not a firmware (at least the primary one)
all it appears to do is count to fff8 (delay?) and jump to $8035
loc_0:
CLD
loc_1:
LDA #$FF
loc_3:
STA $0003
LDA #$F8
STA $0002
LDA #$C1
STA $0001
LDA #0
STA $0000
LDA #0
STA $0004
TAY
loc_16:
CLC
LDA $0000,Y
ADC $0004
STA $0004
INC $0000
BNE loc_23
INC $0001
loc_23:
LDA $0001
CMP $0003
BNE loc_16
LDA $0000
CMP $0002
BNE loc_16
LDA $0004
STA $FFF9
NOP
JMP $8035
can test code at http://skilldrick.github.io/easy6502 (http://skilldrick.github.io/easy6502)
The 6502 memory map looks vaguely like this (derived from staring at the schematic):
$0000-$1FFF (4864 RAM)
$2000-$3FFF (Dallas RAM; repeated 4 times)
$4000-$6000 (nothing)
$6000-$67FF (6520, 6821 equivalent; 4 addresses repeated $200 times)
$6800-$68FF (68488 GPIB controller; 8 addresses repeated $100 times)
$7000-$77FF (uPD8279 display/keypad controller; 2 addresses repeated $400)
$7800-$7FFF (nothing)
$8000-$FFFF (ROM; the 27C256 Dave has provided)
The 6502 reads the reset vector from $FFFC (little endian), which indicates a start address of $C800. There, in the ROM, you will find more sensible initialization code.
EDIT: I've been looking at the code and considering doing a dis-assembly. Would that be of use to anybody?
ok, this makes a ton more sense :) thanks
-
Well, the battery must be really marginal, as you'd expect. I just got an Error 8 on the original NVRAM chip, so that's that. Had to re-install the factory cal values from the ROM.
Hi Dave,
When I saw the NVRAM readout, I immediately suspected a stuck bit - notice how all the bytes are '80' or higher?
I would say that the most significant bit is stuck at '1', and I bet that is why it won't work with the chip you copied the (presumably corrupted) content to, and also why it now fails with the original NVRAM chip. The fault could be intermittent (marginal like you wrote), and thereby dependent on which device is reading the chip (either the device or your reader). It's interesting how it worked in the device, but presumably not in your reader (several times, even when resocketed), and then worked again when back in the device... Too bad it's not working anymore at all :)
Cheers,
/Michael
-
I have a working prema 4001 at home. It's a 6.5 digit meter, I think it's basically the same as the 5000 model.
It has a battery backed Dallas chip to and I have a dump from that at home. I'm at work right now but can put a link to the dump later today if it's of any interest.
-
I like Dave's videos immensely, but frankly, this episode was really painful to watch.
The cowboyish attitude, the "let's remove a crucial part of this equipment, it should work without because I say so", the "let's stick inside various pieces of random chips I have laying around ???" (joking) was a grueling experience.
The part had to come out anyway, so why not see what happens when it's powered up without. It's called curiosity, try it some time, you might find something interesting.
It wasn't a random chip, it was a direct non-battery backed SRAM replacement.
How was this "cowboyish"? What possible damage could I have done by doing anything in that video? It's ok, it's a rhetorical question, the answer is it wasn't possible to damage anything.
-
When I saw the NVRAM readout, I immediately suspected a stuck bit - notice how all the bytes are '80' or higher?
I would say that the most significant bit is stuck at '1', and I bet that is why it won't work with the chip you copied the (presumably corrupted) content to, and also why it now fails with the original
No, I didn't copy anything, and I don't have a new chip. I simply put the original chip back and the next day after a few more power-ups and playing around, I got Error 8.
-
When I saw the NVRAM readout, I immediately suspected a stuck bit - notice how all the bytes are '80' or higher?
I would say that the most significant bit is stuck at '1', and I bet that is why it won't work with the chip you copied the (presumably corrupted) content to, and also why it now fails with the original
No, I didn't copy anything, and I don't have a new chip. I simply put the original chip back and the next day after a few more power-ups and playing around, I got Error 8.
The amount your 6047 was off in calibration is about the same as my prema 6001 which suffered the same error (signaled RAM ERROR). I do suspect that it was the factory-data in the chip. Did you compare to the ROM-factory data? What does it measure after a CAL-ON power cycle?
-
The amount your 6047 was off in calibration is about the same as my prema 6001 which suffered the same error (signaled RAM ERROR). I do suspect that it was the factory-data in the chip. Did you compare to the ROM-factory data? What does it measure after a CAL-ON power cycle?
No, the recalled ROM factory data is also out by a similar amount, but in the other direction.
-
If it's of any interest here's the links to the firmware file and the Dallas chip contents for my prema 4001.
https://www.dropbox.com/s/u2njxa5cpl8x78u/PREMA-4001-27c256.BIN (https://www.dropbox.com/s/u2njxa5cpl8x78u/PREMA-4001-27c256.BIN)
https://www.dropbox.com/s/drj0ree7509uqpr/PREMA-4001-ds1220Y.BIN (https://www.dropbox.com/s/drj0ree7509uqpr/PREMA-4001-ds1220Y.BIN)
-
Later Dallas had versions with removable battery packs as well so wave soldering could be used.
you missed the point or misunderstood : wave soldering batteries is a problem due to shorting them in the wave. it is perfectly acceptable to wave solder the dallas or mostke/st parts. the battery is not accessible. the reason for snaphat on the surface mounted parts is because of reflow. the batteries do not like reflow. wave soldering takes 5 seconds tops. a reflow cycle takes 2 to 3 minutes in a chain oven. also inspection and cleaning is problematic as the pins are covered by the hat.
the hat is not designed to be removable. even though you can pry it off : that is not intended usage.
I might accept these reasons if many existing working designs which used a low power SRAM and battery and write protect circuit were not changed to use NVSRAMs. In some cases the existing board was not even changed. I considered altering my 2440 back to the original SRAM plus battery configuration but found a better option.
not sure what you mean here but traditional designs use bug 2/3 a cell packs or packs with rechargeables because even low power rams like the 4316 (6116 compatible) or 4364 (6164 compatible) draw too much idle current. leaking batteires are notorious for destroying boards. with the dip or snaphat leakage cannot occur (it is contained in the device)
The cell used in the snaphat or zeropowers is a small 237 type cell. adding a realtime clock was a bonus.
For some devices they actually released the sequence to put the device back in freeze mode . Data is lost of course.
The data is also lost even while powered externally if the internal battery voltage drops far enough to disable the supervisory circuits.
that's not the point. the factory restore sequence was to be used to be able to re-shelve parts or destroy data. (sanitizing) critical data.
[/quote]
I prefer EEPROMs.
these things were around way before eeproms became avaialble. 2816 are very expensive.. plus they need a dedicated wipe operation before a byte can be written and they are slow to erase and have limited cycles.
only later when serial eeproms were made did they become more robust.
-
I have a working prema 4001 at home. It's a 6.5 digit meter, I think it's basically the same as the 5000 model.
It has a battery backed Dallas chip to and I have a dump from that at home.
Depends on your definition of basically, but my 5000 has a battery backupped 21C14. No easy way to read it.
(http://members.home.nl/baltusg/PREMA3.jpg)
It's the middle one on the left, the other two are regular 2114's. :P
Note the prema chip in the middle that handles communication to the analog pcb. Including the clock to the 6502, coming from the analog pcb. All via the opto's.
Battery not installed yet. I had to calibrate it after the restoration.
I've seen Dave visiting a cal lab, so my guess is that it won't be hard for him to get it calibrated :)
First some recapping and restoration work and than a recal.
You can also calibrate through gpib; you can automate the procedure (which they probably do at Prema).
-
Later Dallas had versions with removable battery packs as well so wave soldering could be used.
you missed the point or misunderstood : wave soldering batteries is a problem due to shorting them in the wave. it is perfectly acceptable to wave solder the dallas or mostke/st parts. the battery is not accessible. the reason for snaphat on the surface mounted parts is because of reflow. the batteries do not like reflow. wave soldering takes 5 seconds tops. a reflow cycle takes 2 to 3 minutes in a chain oven. also inspection and cleaning is problematic as the pins are covered by the hat.
the hat is not designed to be removable. even though you can pry it off : that is not intended usage.
I conflated wave soldering with reflow soldering but my point still stands:
The two-piece assembly protects the lithium battery, contained in the PowerCap (upper half) from the high temperatures of reflow soldering. The module base (lower half) is a small PCB with surface-mount leads, SRAM, and controller ICs. After the module base is surface-mounted, the PowerCap is snapped onto the base to complete the module.
I might accept these reasons if many existing working designs which used a low power SRAM and battery and write protect circuit were not changed to use NVSRAMs. In some cases the existing board was not even changed. I considered altering my 2440 back to the original SRAM plus battery configuration but found a better option.
not sure what you mean here but traditional designs use bug 2/3 a cell packs or packs with rechargeables because even low power rams like the 4316 (6116 compatible) or 4364 (6164 compatible) draw too much idle current. leaking batteires are notorious for destroying boards. with the dip or snaphat leakage cannot occur (it is contained in the device)
The cell used in the snaphat or zeropowers is a small 237 type cell. adding a realtime clock was a bonus.
I mean existing designs which used a primary lithium battery which was hardly likely to leak and low power SRAM were changed. The parts for write protecting the SRAM and monitoring the battery condition were removed and the integrated NVSRAM replaced the SRAM without changing the printed circuit board. I was considering reverting the design on a Tektronix oscilloscope but found a better solution in the form of an EEPROM backed up SRAM.
The data is also lost even while powered externally if the internal battery voltage drops far enough to disable the supervisory circuits.
that's not the point. the factory restore sequence was to be used to be able to re-shelve parts or destroy data. (sanitizing) critical data.
My point is that there is an additional failure mode where the data is not lost but becomes inaccessible because of low voltage to the supervisor circuit from the internal battery. If you disassemble the package and change the battery or apply power, it then becomes possible to access the data again but only applying external power is not sufficient.
I prefer EEPROMs.
these things were around way before eeproms became avaialble. 2816 are very expensive.. plus they need a dedicated wipe operation before a byte can be written and they are slow to erase and have limited cycles.
only later when serial eeproms were made did they become more robust.
They did not call them that but what were effectively serial EEPROMs go back to at least the mid or late 1980s. General Instruments was making them for their TV tuners in the form of the ER1400 1400 Bit Serial Electrically Alterable Read Only Memory and Tektronix used them for a while before replacing them with battery backed up SRAM which they later replaced with integrated NVSRAM without changing the circuit boards. There was some question about the reliability of the ER1400 and it was difficult to use but it was fully specified and in retrospect it looks pretty good compared to the 100% failure rate of its NVSRAM contemporaries.
I agree that EEPROM was problematical then. Of all of the solutions at the time, I would have gone with discrete battery backed up SRAM unless there was some other reason to use a parallel EEPROM and that is still my preference unless a modern serial EEPROM is more appropriate. I have never found the needed write protect circuits to be challenging. I have had too much hardware fail do to SRAM with embedded lithium batteries to ever trust them again.
-
I have a working prema 4001 at home. It's a 6.5 digit meter, I think it's basically the same as the 5000 model.
It has a battery backed Dallas chip to and I have a dump from that at home.
Depends on your definition of basically, but my 5000 has a battery backupped 21C14. No easy way to read it.
I guess you could pull the neighbouring ICs from sockets and buzz out where all the Dallas chip pins are connected, then put jumpers from the empty IC sockets to a programmer. Not convenient though.
-
I conflated wave soldering with reflow soldering but my point still stands:
The two-piece assembly protects the lithium battery, contained in the PowerCap (upper half) from the high temperatures of reflow soldering. The module base (lower half) is a small PCB with surface-mount leads, SRAM, and controller ICs. After the module base is surface-mounted, the PowerCap is snapped onto the base to complete the module.
which is exactly what i wrote in the first place ...
If you disassemble the package
that is not in the scope of intended usage of those devices...
My car breaks down if i run it into a tree... sorry bub. no cigar...
They did not call them that but what were effectively serial EEPROMs go back to at least the mid or late 1980s. General Instruments was making them for their TV tuners in the form of the ER1400 1400 Bit
oh crap, those metal can TO-100 disasters... basically a 100 page 14 bit memory. it didnt even have a decoder on board you had to shift in the row and column selects as single bits out of ten...
ITT had something similar in the NMV30xxx series used for their digivision chipsets. that thing was such a pain that it had a special mode to verify data thresholds.
the problem the cells were so unreliable that you had to set the analog comparator levels for a zero and a one yourself using those registers. then you could read the actual data.. :palm:
you had to request a specific address and read it. it should return 0x55 using a control register you could set the analog memory comparator to get 0x55. reading the next oddress you should get 0xaa. and again you had to tweak the comparator registor.
i once wrote code for that disaster on an ITT cc3000 cpu ,basically a 6502 with an on screen display engine targeted for analog satellite receivers using DMAC and D2MAC.
-
I found this video fascinating. Coincidentally, this week I've been thinking a lot about what kind of RTC battery to use in my project at work and the typical lifetimes I've been seeing are still in the order of 10 years. To see your unit still have a working battery after 27 years or so is pretty astonishing. I guess Dallas know what they are doing, huh?
Looks like that test gear would have been a good investment back when it was fresh off the shelf.
Great vid Dave.
-
Hi Dave,
I wonder what happened to the Prema 6047, is it still in your lab? Have you installed a new NVRAM? Have you tried calibrating this pice of kit? It would be a shame if it is sitting in the lumber-room without being used. While Prema is still servicing their gear I'm pretty sure Mr. Stricker would love to have your unit on his desk.
-branadic-