TDS3014 adventures

[Galen]

just a quick update for the crystal oscillator.  The 75.7575MHz oscillator received today, drop in replaced the 75MHz one, the frequency measurement display right on 1.000KHz for the scope self cal output. 
Now, the only left thing is to make the anchor assembly to hold the handle in place. The price is very expensive, like $80. So I plan to make it myself.

[sicco]

A TDS3034 from eBay, and the DS1742W issue. Finally cracked it.

Pitfall #1: when Dremel-ing for the coin cell inside the 24 pin DIP Dallas RTC, the battery is not always in the same spot. So the first attempt failed, I cut through the 32 kHz crystal and then damaged too much. Start from the top on the right, near pins 12 and 13. That’s where DS1742 has its battery. Need to take all of the battery out, the + is the solder lip that remains. Battery - on pin 12.

Pitfall #2: when ordering a DS1742 on eBay, note that you must have the DS1742W. Only that is the 3.3V device. No -W means it is a 5V unit. And those enter the low power sleep / battery mode at below 4V or so on the VDD pin 24. So that’s always when we have only 3V3 on pin 24 as in the TDS3000.
Workaround if you’re stuck with a 5V unit: bend away pin 24 on the DS1742 (yes you do need a DIP 24 socket anyway) and then flying lead to a 5V line. I used the input of a 5 to 3.3 TO220 regulator IC elsewhere on the main board). Isolate the old VDD pin in the socket. That made my scope boot fully. Before it did only Tek logo, relay one click, floppy on second turning, and then nothing.

So that’s likely why many assumed that China was sending fake, counterfeit DS1742 units. I don’t think so.

The 75.7 MHz crystal module - I thought for a minute it also failed on mine as the 48 MHz unit did show up on the scope i used. But actually it was just that scope (/probe) not having the bandwidth needed here.

Now, I did go through the effort of reloading the DS1742 from eBay with the binary data shared elsewhere on this forum, but at hindsight maybe that was not really needed. Only when trying to program it, i noticed that my unit was a 5 volt type...

[james_s]

You can locate the battery easily using a magnet, it is close to the surface, sometimes even a small bulge is visible.

The DS1742W is obsolete and out of production so if you bought one on ebay that has a recent date code it is one of two things. Either an old part that has been sanded off, blacktopped and re-marked, or a counterfeit part. I have bought Dallas parts from China sellers on multiple occasions and every one of them was one of those two things. The counterfeit ones are easily identified by xray, they are laid out completely differently inside, and in my experience they do not work properly either.

[sicco]

James, thanks for your response. I would have much preferred your patch pcb with the DS1744W - but was afraid about delays in getting that and the DS1744W and the clip-on for it shipped to me in a timely fashion. You don't sell the patch boards do you?

One thing that I'm still in doubt about and what you must know for sure now: was there a need really to copy back the 2 kbytes of data or would it have booted up irrespectively with a blank chip, or a chip with random data, or 0xff or 0x00 in each byte? Some in this forum including me went through the hassle of copying and sharing hex dumps of what was in them when a unit works ok - but is that necessary? Or is the reason the scope doesn't finish booting up simply that it checks what it is writing back in the RAM, or in the RTC registers and then drops into an infinite loop of retrying and failing to read back. Or is it waiting maybe for a tick of the seconds counter which never happens?

My TDS3034 firmware was very old, 2.2, now upgraded that to 3.39.

[voltsandjolts]

I used a blank chip, works fine. IIRC operating hours gets reset.

[james_s]

I don't sell them, I just don't have time to be doing production, especially not for esoteric things like that where the component cost is high and the sales volume likely just a handful of units per year. They are trivial to build though, there is nothing on the board besides the Dallas chip, some headers and a decoupling capacitor that is probably not even really necessary.

[sicco]

How about we design a board that fits into the expansion slot and has the new SMD DS1744W on it, plus maybe the serial port DB9, the VGA connector, maybe a Bluetooth serial, maybe also a Lantronix Ethernet/WiFi to serial module, and maybe a FTDI USB chip or TTL adapter pin row?

The expansion connector seems to have all of the address and databus lines that the DW1742W has. I guess the /CS for the DS1742W is just a selection on a memory bank from the remaining A12..A19 lines. And I guess a ‘dead battery’ (or an ‘over-Dremelled’) DS1742W simply will not get active anymore on the tri state databus. So maybe we can do a Kicad board that not only fixes a dead RTC battery TDS3000 TDS3012, TDS3014, TDS3034, TDS3054 etc etc scope without even opening the case, without soldering, but also gets an affordable Serial interface as a bonus? Serial port as per what’s reverse engineered elsewhere on forum, 74AC245 etc.

With all info on that expansion port on the www fora, this looks like feasible?

Anyone any thoughts? Commercially viable? Guess there must be 1000nds of otherwise perfect but 15-25 years old / dying / dead units that can get a second life for another decade or two?
 

[james_s]

You'd still have to remove the dead DS1742W, it wouldn't magically stop functioning and tristate with a dead battery, it will just be full of random garbage each time you power up. I don't know if the entire address space is accessible from the expansion connector, if it is then something like this might be feasible but it's likely to be quite a complex project. The cartridge shell is probably a good candidate for 3D printing.

[sicco]

Let’s find out if the DS1742 does or does not tri state when battery is dead. Really dead i mean. Not just no longer ticking the clock, but also no longer NVRAM persistence. Reason why I suspect it would go tri state always with a really dead battery is that others mentioned that it does not matter what’s in them: garbage, zeros, whatever. If it has good VDD, but really dead battery, one would expect that the scope finishes booting instead of doing only Tek welcome screen, one relay click, one second of floppy drive activity, and then nothing. But I think it does not do that. So...

Anyway, worst case if it does still output data, we’d need to destroy only a few pins of an old DS1742W, like its VDD, or pull high /CS or /OE. I’d even dare a short wire bridge from VDD to /CS. Easier still than de-solder 24 pins, without any mainboard pcb damage.

[james_s]

Let’s find out if the DS1742 does or does not tri state when battery is dead. Really dead i mean. Not just no longer ticking the clock, but also no longer NVRAM persistence. Reason why I suspect it would go tri state always with a really dead battery is that others mentioned that it does not matter what’s in them: garbage, zeros, whatever. If it has good VDD, but really dead battery, one would expect that the scope finishes booting instead of doing only Tek welcome screen, one relay click, one second of floppy drive activity, and then nothing. But I think it does not do that. So...

Anyway, worst case if it does still output data, we’d need to destroy only a few pins of an old DS1742W, like its VDD, or pull high /CS or /OE. I’d even dare a short wire bridge from VDD to /CS. Easier still than de-solder 24 pins, without any mainboard pcb damage.

It does not, this is already known. The device continues to function normally except it powers up in an unknown state, usually FF in all RAM cells. I have modified several of them to use an external battery and had one develop a faulty connection so the battery was not connected at all. When power is applied the only change is that the battery flag bit is set indicating a faulty battery, all other functions appear normal. Desoldering 24 pins is trivial if you have proper equipment, I can remove one of those ICs in less than 5 minutes without damaging the board. .

[Ordinaryman1971]

I have one of TDS3012 that powers up with white screen, floppy seeks and then just freezes, I know I've read somewhere somebody having the same problem and finding solution but I can't find it.... anybody kind enough to point me in the right direction.
It's not a crystal, it's all good, got it checked already....
Also.... any source of replacement LCD screens by any chance.

[james_s]

I don't know about that hang, but I was able to buy a replacement LCD fairly easily. It's an older part but it's a standard off the shelf industrial TFT that was used in several other applications. I doubt the LCD is the cause of the white screen though.

[Ordinaryman1971]

No, I didn't mean to imply that's the problem in this case... those are two separate questions.
I just wanted to know if there is a source of the LCDs for those scopes.

[jgorsk]

I haven't used my TDS3032B for a few months and I just noticed that the battery
in the DS1742 RTC chip  must be gone. RTC time, operating hours are completely wrong.
Ethernet doesn't work either.

I'm going to replace the chip with the DS1744W but I don't have a good data to program the RTC with.

Could someone share the contents of a good known DS1742 for the TDS3032B please?

[sicco]

Start with power on reset while pressing B TRIG key. That re-inits some. But not all. The Ethernet bits are tricky.
Hex dumps or binary files have been posted on this forum. Maybe not for 3012-b exactly, but give it a try.

[ytsejam]

Just to provide an update here that the Ethernet connectivity issue turned out to be caused by corrupt NVRAM - speaking of which, one way to detect that is if the MAC address of the scope's Ethernet adapter shows in the configuration screen as 08:00:11:01:02:03.
I obtained an NVRAM dump file from another scope and used it on this scope and now network connectivity has been restored. 

Thanks to users YetAnotherTechie and Galen on the forum here for their help sorting this out!

Jusy FYI to the guys here based on my research.

My TDS3014B has a failing DS1742W as well, not yet completely died, since I can still read the MAC address as 08:00:11:xx:xx:xx on the network config page.
TDS3014B can still be powered up correctly, and I can set the time and date without problem, this means READ/WRITE mode for DS1742W is allowed since Vcc acrossed the Vpf.

However, the MAC address can not be read by CPU in this case, which also caused the ethernet connection fails to work.
This is really odds to me, if the DS1742W can run into READ/WRITE mode, then the MAC address should be able to read by CPU.
I then install another working DS1742W from another TDS3014B of mine, and now ethernet connection works well.

I suspect that maybe there might be a period during boot up, the DS1742W can not be read since Vcc is not yet across the Vpf limit,
which causing the MAC address is not read correctly.
So, I give it a try by soldering a CR2025 to pin 24 and 7 of the almost-gone DS1742W, and keep pin 24 lifted (so DS1742W is powered by CR2025 instead of Vcc),
and install it into the IC socket on TDS3014B.
I think this should keep DS1742W powered by the CR2025, so that it is kept in READ/WRITE mode.
But the result is the same, after powering up TDS3014B, the MAC address doesn't work still.

So I'm curious, why the MAC address on an "almost-failed" DS2741W can not be read successfully while the date/time is well read?

[ytsejam]

Start with power on reset while pressing B TRIG key. That re-inits some. But not all. The Ethernet bits are tricky.
Hex dumps or binary files have been posted on this forum. Maybe not for 3012-b exactly, but give it a try.

The TDS3012B.hex posted has been replaced with a JPG picture.
Try to rename the suffix from hex to jpg.

[sicco]

On the older  TDS3000 no-suffix, the MAC address does not reside in the NVRAM, but on a flash rom on its plug-in board TDS3EM. But also there, for Ethernet to really work, it does matter big time what else is in its NVRAM DS1742W. Settings related to DHCP yes/no, subnet masks etc. For the -b models it might still be the case that the MAC address is not in the DS1742W. But other Ethernet settings for sure will be in the NVRAM.

Even though the scopes can see that NVRAM is bad (they will say so at 38400,n,8,1 on the first ttl serial port while booting up), and even though it then reinitialises to default settings like one channel only) it fails to properly set those Ethernet values. Only way to get Ethernet working again is to program NVRAM with known-good data, as you did. Same for holding down B TRIG while booting: it forces to re-init  most of the NVRAM but fails to re-init the Ethernet settings bits.

[YetAnotherTechie]

My TDS3014B has a failing DS1742W as well, not yet completely died, since I can still read the MAC address as 08:00:11:xx:xx:xx on the network config page.

"Its dead Jim"

A scope with a corrupted or cleared NVRAM will still show a seemingly correct MAC address in the config page. That address doesn't work, and it's not being used by the scope. The only way to have a correct address is to program the NVRAM correctly.

[ytsejam]

Thanks YAT and sicco for the response.

Get it fix is not something what I was after, just curious why.
I'm pretty sure that MAC address is stored in the NVRAM, if I swap the DS1742W with a new one, MAC address shown in the network config page is all zero.
BTW, IP/subnet mask/ gateway settings are stored in the flash instead, that's why even if you swap the NVRAM with a new one, IP/mask/GW are still there.

But, sicco did remind me a point related to DHCP.
Actually, the real issue is the BOOTP instead of DHCP.
BOOTP allows you to boot the system from network before loading the OS, and the scope needs a MAC address for that at the very beginning of booting process.
Which means MAC address will be read very early, and if at that moment, the NVRAM is not yet powered up, or entering the R/W state, it relies on internal battery to work.
I think this might be a reasonable explanation.

[sicco]

Again, speaking only for the older -no_suffix models, the MAC address is physically stored on the flash chip on the TDS3EM. I know for sure because that's where I put it when I make my 'TDS3000 Second Life Boards'. Also, for the original TDS3EM, why else would you have a sticker on them with the MAC address that they (and not the scope) has been programmed at ex factory). The first three bytes are 'Tektronix' and actually editing the 08:00:11:xx:xx:xx into something not starting with 08:00:11 also means the scope will refuse to do Ethernet!

It may well be that some bytes in the NVRAM hold BOOTP vs DHCP vs manual modes for IP address, subnet masks etc. Possibly options for other legacy networking standards, who knows... These 'hidden' settings are not user editable and also not decently factory-defaulted when scope sees NVRAM is corrupted.

BTW, for those interested in reloading TDS3000 NVRAM the easy way, so without taking it out of the scope mainboard and putting it in an EPROM programmer: see my latest 'budget version' for the 'TDS3000 Second Life Board'. Now with a FT4232 that does not only get you both serial ports on USB, but also is a BDM backdoor into nearly everything inside the scopes. A good old PC command line C program now reads, edits, writes everything with bytes/hwords/words inside: the motherboard flash chips, the RAM after VxWorks has loaded the application, the DS1742W of course, everything inside the XPC860 PowerPC, but also any I2C Expansion Module you might have slotted into the front panel  .

And of course there's a DS1744W on board to take over the role for the mainboard DS1742W with the dead battery.

Still planning for a next version that has its own uController and a RTC with coin cell battery. One with a male and female 100 pins connector, so that other plugins like IEEE GPIB could still be fitted (but stick out an inch or so further). This will then copy battery backed NVRAM + clock/calendar data into the old DS1742W at boot time, keeping the PowerPC in debug mode for a second or so while copying the real real time clock and the battery backed settings. Then reboot the PowerPC. An dthen catch breakpoints on writes into NVRAM, and copy the data in real battery backed data on this expansion module. Anyone interested?

PS ytsejam, on your direct wiring 3V battery to main board DS1742W pin 24 VDD: be aware that when the scope if powered off, it will mean you have /CS, /WE and /OE all pulled low, so expect your battery to run flat faster than what you might have hoped for...
 

[ytsejam]

Again, speaking only for the older -no_suffix models, the MAC address is physically stored on the flash chip on the TDS3EM. I know for sure because that's where I put it when I make my 'TDS3000 Second Life Boards'. Also, for the original TDS3EM, why else would you have a sticker on them with the MAC address that they (and not the scope) has been programmed at ex factory). The first three bytes are 'Tektronix' and actually editing the 08:00:11:xx:xx:xx into something not starting with 08:00:11 also means the scope will refuse to do Ethernet!

It may well be that some bytes in the NVRAM hold BOOTP vs DHCP vs manual modes for IP address, subnet masks etc. Possibly options for other legacy networking standards, who knows... These 'hidden' settings are not user editable and also not decently factory-defaulted when scope sees NVRAM is corrupted.

BTW, for those interested in reloading TDS3000 NVRAM the easy way, so without taking it out of the scope mainboard and putting it in an EPROM programmer: see my latest 'budget version' for the 'TDS3000 Second Life Board'. Now with a FT4232 that does not only get you both serial ports on USB, but also is a BDM backdoor into nearly everything inside the scopes. A good old PC command line C program now reads, edits, writes everything with bytes/hwords/words inside: the motherboard flash chips, the RAM after VxWorks has loaded the application, the DS1742W of course, everything inside the XPC860 PowerPC, but also any I2C Expansion Module you might have slotted into the front panel  .

And of course there's a DS1744W on board to take over the role for the mainboard DS1742W with the dead battery.

Still planning for a next version that has its own uController and a RTC with coin cell battery. One with a male and female 100 pins connector, so that other plugins like IEEE GPIB could still be fitted (but stick out an inch or so further). This will then copy battery backed NVRAM + clock/calendar data into the old DS1742W at boot time, keeping the PowerPC in debug mode for a second or so while copying the real real time clock and the battery backed settings. Then reboot the PowerPC. An dthen catch breakpoints on writes into NVRAM, and copy the data in real battery backed data on this expansion module. Anyone interested?

PS ytsejam, on your direct wiring 3V battery to main board DS1742W pin 24 VDD: be aware that when the scope if powered off, it will mean you have /CS, /WE and /OE all pulled low, so expect your battery to run flat faster than what you might have hoped for...
 

Hello sicco,

Thank you!
The 3V battery is just for experiment, was trying to make sure the NVRAM can be stay in R/W mode during scope boot-up process.
I have read through your 2nd-Lift-Board, that's a really great work!

And your are right, if the non-B version and the B/C version of TDS3000 have different procedure in loading the MAC address, restoring NVRAM data into DS1742W on the mainboard from 2nd-Life-Board is a better way then direct writing into the Flash, since non-B and B/C version might have different Flash arrangement.

I'll focus on the NVRAM as of now, since I got a DPO3054 as well, which has the almost the same issue with TDS3000, and I will face the same problem sooner or later.
I'll have the EEPROM programmer arrived this week, and will dump/copy/backup the NVRAM first and then find the checksum for figuring out a way to program NVRAM directly.

[ytsejam]

"Its dead Jim"

A scope with a corrupted or cleared NVRAM will still show a seemingly correct MAC address in the config page. That address doesn't work, and it's not being used by the scope. The only way to have a correct address is to program the NVRAM correctly.

Update after reading the DS1742W with programmer

1. The reason for why a scope with a dying NVRAM which still stores MAC address, can't make it work with Ethernet: As YetAnotherTechie mentioned, the content of the NVRAM is corrupted.

I tried to read the NVRAM with the programmer, even with a battery attached externally, dumped result are not the same almost every time.
This inconsistency will make the scope CPU ignore the content of NVRAM eventually. That's why the MAC address will not be applied.

2. Confirmed the MAC address of the TDS3000B model is stored in the NVRAM at offset 0x06F0 - 0x06F5

3. Power-On hours is located at offset  0x07E0 - 0x7E3, in minutes. After boot up, the system will convert it into hours and shows it in the Diagnostic page.

4. No checksum were found, I modify the NVRAM dump of another TDS3000B with working NVRAM, changed the MAC address portion, and write it to a new DS1742W for the one with problem. System boot-up correctly with new MAC address applied and Ethernet is working perfectly.

[Maxis]

Hello Sicco,

I have a non-suffixed 3014 model converted to 3054. I plan to retrofit the serial port and Ethernet according to your project schematics. Could you, please, answer a couple of questions:
- Is there a FLASH FW extension in the original TDS3EM module or all the ETHERNET FW is already stored in the o-scope FLASH?
- Have you managed to get the Ethernet port working? If not then does it hang during the boot sequence with the Ethernet option enabled? How does the problem look like?

Thank you for your incredible efforts in bringing the modern connectivity to our favorite scopes. You have done a great job!

BR

Maxim

[sicco]

Hi Maxis,

The Flash rom on the TDS3EM only has a MAC address, coded as an ascii string, null terminated with colons in between the bytes. I attach an example. If that's not found in a -no-suffix TDS3000 while a plugin module claims to be a TDS3EM, then it will complain about this via the first serial port (only the second serial port normally goes to an expansion module RS232 connector, but there's a first one also, see earlier posts).

It is vital that the MAC address starts with 08:00:11:xx:xx:xx - so only change the xx values.

 

It is vital also to have the NVRAM settings correct, and although a blank or corrupted NVRAM gets restored to most default scope settings, it fails to properly reset the Ethernet settings that are not user editable from the keyboards utility menus. I think it is more than a copy of that MAC address, but I don't know for sure which NVRAM bytes are the ones that cause trouble (like scope hangs when setting it DHCP, scope no longer finishes normal boot once DHCP is enabled etc). The workaround is to just load the NVRAM with a known good working image. Attached also.

To edit the NVRAM, either take out the DS1742W and use something like an EPROM programmer with a DIP24 socket. Or, much easier, use the BDM port. I used Swiss made unit Abatron BDM2000 initially, but now have plugin boards with FT2232 mini module or FT4232 on board, and that's even easier for editing. Not just the NVRAM, but also the main board Flash ROMs (so that we can update models "-any" firmware to unlock weird bandwidth restrictions that may have been put in ex-factory by marketing forces. Or by export controls police departments, who knows... Also you can edit the I2C EEPROMs inside the Option Modules that you may still have in your scope. Mostly just for the fun because you likely have FFT and Advanced trigger options already working since going v3.41, and then there's only just one or two options left - weird options that you'd not want anyway I guess.

I still have two 'Second Life TDS3000' plugin boards (ref the pdf manual shared 2 posts earlier) that I happily sell for EUR 175 each, ex shipping. I will have another 3 'budget version TDS3000 second life' boards next week - only those have the BDM FT4232 fitted. They do not have Ethernet though. They ship at 125 EUR each. With PC software for making the edits.