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

0 Members and 1 Guest are viewing this topic.

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: 2307
  • 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: 30286
  • 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: 30286
  • 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: 30286
  • 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
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7265
  • 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: 10316
  • 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.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7265
  • 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