Topics

TDS3054 Replacement of DALLAS DS1742W (U640), data content in NV-RAM


maddisassembler
 

Hello all,

a TDS3054 (built in year 2001) shows the following symptoms when connected to power:
- 'A system error has occured', Error Count =11, 'display error', goes away after short power off/on
- Unrealistic high 'total operation time' (16350105 hours)
- Impossible time setting (e.g. '11:80:21')

Topic #157465 also deals with this issue, the problem is data corruption inside
U640 DALLAS DS1742W, exhausted lithium battery, date code on the
package is '0029'.

I ordered replacement DS1742W via Amazon in China (the chips I received seem fully functional when
tested on a programmer), date code on the package is '0945'.

How should I prepare the new DS1742W I am going to install in the scope?

Simply read out the (most probably) rubbish of the old DS1742W and copy
it to the new one?

Is a memory map available somewhere which shows the addresses of the
relevant memory locations and their expected content in a working scope?
(the address locations 0x7F8...0x7FF are described in the DS1742W data
sheet)

I cannot believe that appr. 2k of memory are fully used to store internal scope
status data.

Thanks for any help!

Best regards
-Roland


amirb
 

you can just throw in a completely blank chip in there, no problem
reading the old chip and writing in the new one doesn't do much and doesn't do any harm either as I have learned...specially now that the # of hours is messed up

the number of hours are stored in minutes (in HEX) at 07E0-07E3 and also at 07E8-07EB (the same number repeated)
that's probably the only thing you need


Mark Litwack
 

A DS1742W from China? Chances are really high it's a counterfeit. Here's an eevblog thread that has some pictures of a China fake vs real:

https://www.eevblog.com/forum/repair/repair-of-tek-tds3014b-need-a-source-for-a-ds1742w-nvram/msg2644260/#msg2644260

The dimensions are a giveaway, at least on that one.

Further in that thread, there's a link to someone who made an adapter board for a DS1744WP, which is still available from reputable sources (Mouser, Digikey, etc). Functionally, it's the same as the DS1742W, but with more SRAM that would never be accessed. The adapter board fits TDS3000 scopes.

I ended up doing surgery on my old DS1742W to connect an external battery. I'd recommend not throwing away your old DS1742W, and install a DIP socket.

-mark


maddisassembler
 

Hello all,

thank you very much for your replies. Here is my list of
actions (so far):

1.
The 'chinese part' worked ok in a programmer (readable,
writeable, reasonable content in the registers 0x7F8...0x7FF), also see
my question A. below

2.
I desoldered the old DS1742W from the TDS3054 mainboard and
replaced it with socket strips

3.
I programmed the chinese DS1742W with all 0xFF in the address range
0x000...0x7F7 (not touching the registers).

4.
I put the chinese DS1742W into the socket and powered the scope up for
a couple of minutes and to have a look into the system menus.
- date/time appeared as '6 Apr 22 2:40:80' (not counting up)
- Cal menu text: 'The last factory calibration occurred 0 (operating) hours
ago on 19-Dec-2001
- Cal menu text: 'The last SPC occured 0 (operating) hours ago on 8-Nov-2006'
- System Errors: 15, Display Errors: 15 (so no errors on other subunits)
- Total operating time: 0 hours
- Number of Power Ups: 206
Also see my question B. below


5.
After shutting down the scope I read out the chinese DS1742W on the
programmer to see which entries had been changed from 0xFF to
something else. Following is the RAM content by address:
0x000 ... 0x297, mixture of random-looking values
0x298 ... 0x61F, all bytes 0x00
0x620 ... 0x63F, all bytes 0xFF
0x640 ... 0x6DB, mostly 0x00 but also non-zero values in between
0x6DC ... 0x7DF, all bytes 0xFF
0x7E0...0x7E3, 4 bytes: 0x00 0x00 0x00 0x04
0x7E4 ... 0x7E7, 4 bytes: 0x00 0x00 0x00 0x04
0x7E8...0x7EB, 4 bytes: 0x00 0x00 0x00 0x04
0x7EC ... 0x7EF, 4 bytes: 0x00 0x00 0x00 0x00
0x7F0 ... 0x7F7, all bytes 0xFF
0x7F8...0x7FF, register map as described in datasheet.
Also see my question C. below


Questions and remarks:

A.
What 'special characteristics' can be found with a
chinese fake chip? Is it an empty housing containing
nothing but only rows of pins sticking out?
My chinese version had the exact physical
appearance of the housing and the same look of the
potting from the bottom side.
Weight:
Chip from TDS3054: 7,21g
Chinese DS1742W: 7,38g

B.
The clock cannot be running because the /OSC-bit
register 0x7F9 bit7 is set to '1'. The scope obviously
does not reprogram this bit.
The number of power ups seems to be stored somewhere
else but not in the DS1742W. The value of '206' is ok because
it was at '203' when the scope operated correctly the last time
before the DS1742W failed.

C.
The scope seems to write nearly into the whole memory,
the content at 0x000 ... 0x297 seems to be 'mystery' (or
perhaps random garbage).
The value (hex) 00 00 00 04 appears 3 times. Could it
be that the total operating time is stored 3 times
(and not twice as written by AMIRB)?
The value 4 is reasonable because the scope was
switched on for about 4 minutes.
Any remarks on the meaning of the other values?

Thanks again!

Best regards
-Roland


amirb
 

some of the chinese fakes do actually work and identical to the original but since their date code is also old they ma not last that long
I also got several fakes that didnt work until I got this one that worked as yours does. The fakes that didnt work are visibly larger in size than the original one
I also got a fake one that worked perfectly fine as DS1742 but not as a DS1742W !
but I am surprised that why your clock is not working. The chip that I got worked. But as I said the date code is already 12 years old so it may not last
assuming that it is a real date code!

as far as I know the hours are stored at those two places. when I changed both to a new number the scope showed the correct # of hours


David Kuhn
 

Look up " james_s <https://www.eevblog.com/forum/profile/?u=127611>" on
EEVBLOG. He has a much better solution. i would show you a picture, but I
don't know how in here.

On Sun, Aug 30, 2020 at 12:23 PM maddisassembler <
320041677522-0001@...> wrote:

Hello all,

a TDS3054 (built in year 2001) shows the following symptoms when connected
to power:
- 'A system error has occured', Error Count =11, 'display error', goes
away after short power off/on
- Unrealistic high 'total operation time' (16350105 hours)
- Impossible time setting (e.g. '11:80:21')

Topic #157465 also deals with this issue, the problem is data corruption
inside
U640 DALLAS DS1742W, exhausted lithium battery, date code on the
package is '0029'.

I ordered replacement DS1742W via Amazon in China (the chips I received
seem fully functional when
tested on a programmer), date code on the package is '0945'.

How should I prepare the new DS1742W I am going to install in the scope?

Simply read out the (most probably) rubbish of the old DS1742W and copy
it to the new one?

Is a memory map available somewhere which shows the addresses of the
relevant memory locations and their expected content in a working scope?
(the address locations 0x7F8...0x7FF are described in the DS1742W data
sheet)

I cannot believe that appr. 2k of memory are fully used to store internal
scope
status data.

Thanks for any help!

Best regards
-Roland