Author Topic: EEVblog #615 - Prema 6047 Multimeter Followup  (Read 21620 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
EEVblog #615 - Prema 6047 Multimeter Followup
« 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
ROM is here:
http://www.eevblog.com/files/Prema6047-ROM-8-5-91.BIN

 

Offline Chipguy

  • Supporter
  • ****
  • Posts: 303
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #1 on: May 11, 2014, 08:30:09 am »
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
Where is that smoke coming from?
 

Offline Switching Power

  • Contributor
  • Posts: 16
  • Country: nl
  • professional hobbyist and design engineer
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #2 on: May 11, 2014, 08:42:28 am »
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 :)
 

Offline Dr. Frank

  • Super Contributor
  • ***
  • Posts: 1753
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #3 on: May 11, 2014, 09:39:04 am »
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 
 

Offline justanothercanuck

  • Frequent Contributor
  • **
  • Posts: 390
  • Country: ca
  • Doing retro repairs...
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #4 on: May 11, 2014, 01:17:55 pm »
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.)
Maintain your old electronics!  If you don't preserve it, it could be lost forever!
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #5 on: May 11, 2014, 01:35:21 pm »
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.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2308
  • Country: 00
    • My random blog.
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #6 on: May 11, 2014, 02:15:04 pm »
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

Code: [Select]
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
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Online free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #7 on: May 11, 2014, 02:26:11 pm »
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.
« Last Edit: May 11, 2014, 02:38:51 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Online edpalmer42

  • Super Contributor
  • ***
  • Posts: 1680
  • Country: ca
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #8 on: May 11, 2014, 03:35:13 pm »
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
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #9 on: May 11, 2014, 04:17:48 pm »
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.
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 15281
  • Country: za
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #10 on: May 11, 2014, 04:45:44 pm »
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.
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 5768
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #11 on: May 11, 2014, 06:00:24 pm »
Might it be possible to replace the battery RAM with an EEPROM?
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline Chipguy

  • Supporter
  • ****
  • Posts: 303
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #12 on: May 11, 2014, 06:10:31 pm »
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
Modify message
Where is that smoke coming from?
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 10324
  • Country: us
  • DavidH
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #13 on: May 11, 2014, 06:15:09 pm »
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.

Quote
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.

Quote
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.
 

Offline tpw_rules

  • Regular Contributor
  • *
  • Posts: 50
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #14 on: May 11, 2014, 06:25:48 pm »
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

Code: [Select]
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

The 6502 memory map looks vaguely like this (derived from staring at the schematic):
Code: [Select]
$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?
« Last Edit: May 11, 2014, 07:01:56 pm by tpw_rules »
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 10324
  • Country: us
  • DavidH
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #15 on: May 11, 2014, 06:28:09 pm »
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. :)

Quote
An EEPROM will not work because it needs waiting time after each write, the software would have to be modified   :scared:

True enough.

Quote
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."

Quote
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.
 

Offline Chipguy

  • Supporter
  • ****
  • Posts: 303
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #16 on: May 11, 2014, 06:50:28 pm »
Quote

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.


Where is that smoke coming from?
 

Offline quarks

  • Frequent Contributor
  • **
  • Posts: 830
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #17 on: May 11, 2014, 07:39:33 pm »
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.
« Last Edit: May 12, 2014, 06:49:12 am by quarks »
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #18 on: May 11, 2014, 09:22:19 pm »
There's also this option...



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.
« Last Edit: May 11, 2014, 09:24:03 pm by Stonent »
The larger the government, the smaller the citizen.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #19 on: May 12, 2014, 02:41:29 am »
It's a hack but it would work.

Why would you bother?
You can still buy the DS1220
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #20 on: May 12, 2014, 02:42:54 am »
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.
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #21 on: May 12, 2014, 02:50:23 am »
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.
The larger the government, the smaller the citizen.
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #22 on: May 12, 2014, 02:51:00 am »
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?
The larger the government, the smaller the citizen.
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 15281
  • Country: za
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #23 on: May 12, 2014, 04:36:41 am »
He probably did. Would be interesting to see the new values in the chip now to compare them.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #24 on: May 12, 2014, 05:28:48 am »
You didn't save the contents of the original Dallas chip?

Hu? The whole video was about doing that.
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List
 

Offline quarks

  • Frequent Contributor
  • **
  • Posts: 830
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #25 on: May 12, 2014, 07:10:51 am »
There's also this option...



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


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.
 
« Last Edit: May 12, 2014, 07:39:31 am by quarks »
 

Offline Balaur

  • Supporter
  • ****
  • Posts: 525
  • Country: fr
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #26 on: May 12, 2014, 07:29:16 am »
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.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2308
  • Country: 00
    • My random blog.
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #27 on: May 12, 2014, 07:39:38 am »
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

Code: [Select]
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

The 6502 memory map looks vaguely like this (derived from staring at the schematic):
Code: [Select]
$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
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline Miwer

  • Contributor
  • Posts: 13
  • Country: dk
  • Michael
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #28 on: May 12, 2014, 09:46:37 am »
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
« Last Edit: May 12, 2014, 09:57:18 am by Miwer »
 

Offline carpelux

  • Regular Contributor
  • *
  • Posts: 66
  • Country: se
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #29 on: May 12, 2014, 11:19:26 am »
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.
---------------------------------------
Catch the light
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #30 on: May 12, 2014, 11:27:23 am »
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.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #31 on: May 12, 2014, 11:29:14 am »
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.
 

Offline wiss

  • Frequent Contributor
  • **
  • Posts: 485
  • Country: ch
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #32 on: May 12, 2014, 12:01:16 pm »
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?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30292
  • Country: au
    • EEVblog
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #33 on: May 12, 2014, 12:06:56 pm »
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.
 

Offline carpelux

  • Regular Contributor
  • *
  • Posts: 66
  • Country: se
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #34 on: May 12, 2014, 04:27:01 pm »
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/drj0ree7509uqpr/PREMA-4001-ds1220Y.BIN
---------------------------------------
Catch the light
 

Online free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #35 on: May 12, 2014, 07:00:38 pm »
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.


Quote
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.



Quote
Quote
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.
Quote

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.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline guido

  • Regular Contributor
  • *
  • Posts: 207
  • Country: nl
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #36 on: May 12, 2014, 10:07:51 pm »
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.

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).
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 10324
  • Country: us
  • DavidH
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #37 on: May 12, 2014, 10:47:21 pm »
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.

Quote
Quote
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.

Quote
Quote
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.

Quote
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.

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.
 

Offline krivx

  • Frequent Contributor
  • **
  • Posts: 763
  • Country: ie
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #38 on: May 12, 2014, 11:01:12 pm »
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.
 

Online free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #39 on: May 12, 2014, 11:34:29 pm »
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 ...

Quote
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...

Quote
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.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline wosser

  • Contributor
  • Posts: 27
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #40 on: May 14, 2014, 05:19:37 pm »
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.
 

Offline branadic

  • Super Contributor
  • ***
  • Posts: 1509
  • Country: de
Re: EEVblog #615 - Prema 6047 Multimeter Followup
« Reply #41 on: December 28, 2017, 05:01:23 pm »
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-
Fluke 8050A | Prema 5000 | Prema 5017 SC | Advantest R6581D | GenRad 1434-G | Datron 4000A | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Prema 5017 SC, 34401A, 34410A, Keithley 2182A, HDO6054, Keysight 53230A and other goodies at work
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf