TDS3014 adventures

[james_s]

So I scored this dead TDS3014 for free, initial investigation was not promising, all the voltages looked good but there were no signs of life other than the backlight. Then upon further investigation I noticed that one of the two oscillator cans didn't seem to have any output. Could it really be that simple? I poked around and measured both and found identical conditions on the other pins but this one had no output. I thought perhaps something was shorting the output but I'd expect to see *something* on the output in that case but this was flatlined.

Ok so I start digging through my stash of scrap boards I found a similar looking 28MHz oscillator, nowhere near the 75.75MHz of the original but I thought it might at least invoke some small sign of life and tell me if I was on the right track. So I popped that in and imagine my surprise and elation when I hit the power switch and the scope burst to life with the splash screen immediately appearing on the screen. Woohoo!! Then it proceeded to boot up fully and display a trace, although not too surprisingly it feels very sluggish. Still, progress! Seeing formerly dead equipment spring back to life is the sort of thing that makes life worth living 

Sooo now I need a 75.75MHz oscillator, I have to assume that Tek had a good reason for using an odd value like that. I have not had much luck with the usual suppliers but maybe I've missed something. The original part is a Fox 401 series with a 5x7mm package, powered by 3.3V. I'm not opposed to adapting something in a different package if I need to. I'm open to buying a used part if anyone has one, maybe one of you has a scrap  TDS mainboard with bad ASICs or something?

I need some knobs too, oddly a bunch of them are crumbling to bits, those are readily available on ebay though. I'd also love to find the optional comm module but first things first.

[texaspyro]

There are a lot of programmable oscillator chips out there these days.   Most distributors of these devices offer programming services.

[DaJMasta]

If it'll run on a 28MHz oscillator, you may be able to get something in the same ballpark (70-80MHz) that will work fine.  It would be worth checking timekeeping functions and stuff, but if it's got an RTC, the sampling should be controlled by its own clock, so it may not actually be that critical to nail the frequency.  There's definitely the chance it's important, as you mention, but it's worth trying.

It's an odd number for a signal generator, but if you can generate the frequency (or maybe like a 25.25MHz squarewave and filter out the fundamental) you can probably test to see if it actually is the thing that needs the fix.

Another potential replacement option is a VCO or DDS generator chip capable of generating your frequency, but it's probably worth looking around for a crystal first, as it would be a bunch of extra stuff to do.


Is it possible that it's not actually a 75.75MHz oscillator and that's some other package marking?

[james_s]

I actually was just coming here to say I ordered a programmable oscillator from digikey that theoretically ought to be a drop-in replacement. It was only about 8 bucks so worth a shot at least.

It boots with the 28MHz oscillator but it doesn't really work properly. It will display the compensator waveform and the menu works for the most part but a lot of things feel weird. I'm going to wait until the new part comes before I bother to mess with it further.

In the meantime I've been doing a deep cleaning. The plastic on this thing is crazy brittle and I've had to glue a few clips and tabs. Almost every one of the knobs has cracked into pieces too, maybe the high temperature from being in Hawaii? I bought a set of new knobs that will fix that right up. The screen also has a bit of weirdness that turns out to be some delamination of the rear polarizer film. Since there is also one stuck pixel I may splurge and spend the 80 bucks or so on a replacement but that can also wait until it's fully working.

Is there a way to hack it into the 500MHz model without the comm module? Looks like people want a few hundred bucks for that option module and I have no real use for it beyond unlocking features.

[james_s]

So I was messing around at my bench today and the oscillator from the scope was sitting there still so I decided to solder some wires to it and play around. In the process I cleaned the rust off and noticed that it actually says 75.757 on it which I'm fairly sure is the frequency as there is another identical part in a different area that says 48.000 which is a frequency I've seen elsewhere.

Anyway I hooked it up to power and yep, still stone dead. I tried turning the voltage up as high as about 6V with no signs of life, then I turned the voltage down and was surprised to note that when I got down to around 2.2V it woke up, with an output of about 25MHz. I could turn the voltage up and the waveform would start to get ugly and then abruptly around 2.8V it would suddenly go dead, turn the voltage down and it would wake up again. I experimented, heating it up to the point where the wires desoldered from it and up until then the characteristics changed very little except it would run at a slightly higher voltage. I then used freeze spray to make it very cold and again surprisingly little difference.

So I'm really curious at this point what is going on with this thing. Is it likely that it is itself a programmable oscillator with a 25MHz source clocking an internal PLL that has failed? It's academic at this point since it's obviously defective but this is not a failure mode I've ever encountered or expected.

[james_s]

Oh hang on a sec, the frequency it's running at is almost precisely 1/3rd of the expected 75.757 MHz, is it possible that the crystal is oscillating in the wrong mode? I am not very knowledgeable about crystal oscillators but I do recall there are multiple frequencies they can oscillate at depending on how they are driven.

[edavid]

Oddly enough, it seems to be a standard frequency... this company sells them for $1.44 each:

https://www.knjn.com/ShopOscillators.html

Or maybe you could get a sample from Ecliptek:

http://www.ecliptek.com/stocksearch/stock.aspx?PartNumber=EHF1125TS-75.757M

I think it would be better to avoid using a programmable oscillator, since they tend to have high jitter, which is really not great for an oscilloscope sampling clock.

[james_s]

Oh hey that's great, that place hadn't come up in any of my earlier searches. Never heard of them before but I ordered one and will see what happens.

[james_s]

The new oscillator arrived today so I installed it and I'm pleased to report that the scope is now working perfectly! While I was waiting for that, I completely disassembled the scope and cleaned everything, bought a full set of replacement knobs for $60 since the originals were all cracked or broken, and I bought a NOS display for $65 because the original had the rear polarizer starting to delaminate, a stuck pixel and the backlight was getting tired. I reflashed one of the option modules with the code that unlocks all the features and now finally I put it all back together. All four channels work, all the buttons and knobs work, floppy drive works, everything great. I'm super excited to have this.

The only negative is that the plastic is all crazy brittle for some reason, I had to glue a number of clips and I'll need to be gentle with the rest of the thing, I have no idea why that's so bad or if there's anything that can rejuvenate brittle ABS. Also it doesn't have a comm module so I can't do the 500MHz bandwidth upgrade. Anyone got one of those for less than ebay prices, maybe even  one I can borrow briefly to do that? Serial or GPIB is fine.

[giosif]

Still holding a grudge for getting the scope before me  , but have to admit it's definitely in better hands than mine.
I would have never thought of checking something like the oscillator.
Nice job with the repair! 

[james_s]

Well if it makes you feel any better, I never win anything and am never the first to encounter and jump on a deal like this, so this is probably a one-off experience   

As far as the oscillator, once I'd checked all the voltages, it kind of seemed like the next logical place to look since there was no sign of any activity anywhere. Once I get sucked into a project like this I tend to obsess over it and power through it until I'm finished.

[giosif]

Ok, no grudges anymore. 

That is good, to get focused on a project until it's done.
Others... ok... Me, I tend to start a few projects in parallel and I have the feeling that leads to more of them ending up in limbo state.

[james_s]

Oh I absolutely have that problem as well, but then occasionally something like this gets me excited and I really focus on it and don't get stuck to the point of burning out.

I ended up taking this apart again last night after I noticed the RTC was stopping when it was powered off. Obviously the battery in the dreaded DS1742 was failing although it still was keeping the data in the SRAM. At one point in time I thought those Dallas chips with the integrated battery were a neat idea but after dealing with discontinued older ones I now in a handful of devices think they are absolutely stupid, I mean how hard would it have been to build a coin cell holder into the top? Lithium coin cells almost never leak but I digress. Anyway I desoldered the chip and installed a socket, then popped it in my TL866 and read it as an EEPROM saving the contents to a file.

Then on to the surgical procedure, first cut the plastic shell with a razor knife and carefully peel off a section to expose the epoxy. With the help of a little hot air I softened the epoxy and carefully dug out the old battery which I then measured out of curiosity and found it was only 0.6V, pretty remarkable that it held the NVRAM contents. In this scope there was sufficient space that I was able to graft a CR2032 holder right onto the top of the chip, it's not pretty but it does the job.

Pop it back in the TL866 and load the contents back on it, then install it back in the scope and power that up for a test. All looks good, reference waveforms still intact, date and time are waaaaay off so I set those and it appears to be working fine. Then I check the error log and wait a sec, ok that's not right, I'm reasonably confident that this scope has not been powered on continuously since the year 213 BC unless I've stumbled into something *really* strange. I suppose it would explain the brittle plastic though.

Ok so back to the drawing board. Pop the newly modified Dallas chip out and back into the TL866 it goes. A couple hours of messing around and dozens of back and forths between the scope and programmer and eventually I figured out that reading these Dallas NVRAMs in the TL866 is not reliable, it seems the first read is almost always corrupted to some degree but read it a couple more times and it gets a clean read. Unfortunately I had only that one dump that I did initially so now I'm *really* glad that the calibration values are not stored in this as on some older scopes, incidentally neither are the power-on cycles. I worked out experimentally that the power on hours are stored in a series of bytes starting at x7E0. I'm not absolutely positive of the format but I suspect the time is stored as seconds, before realizing this I experimentally found that x0210 resulted in a display of 2252 hours which is pretty close to what it had prior to this little adventure. At this point I decided to quit while I was ahead and call it good before I break a pin off the DS1742 or plug it in wrong and fry something while trying to get the hours exactly right.

Sooo back together, put it through its paces and now I'm fairly confident that it's 100% working now. I bit the bullet and bought a GPIB/RS232/VGA comm module for $240 which is more than I had invested in the whole project up until now but I figure I'm still ahead as this should allow me to turn it into what is effectively a TDS3054 which I can take advantage of when needed by borrowing probes from my TDS784C boat anchor.



Once the dust settles and I'm satisfied that this is going to stay working I think I might try to repay the generosity that got me this thing and offer the TDS320 I've been using as my "portable" scope until now to someone who needs a scope but I need to find a suitable box. It has displayed a calibration error ever since I tried to back up the stupid Dallas chip it uses and getting it calibrated would cost more than it's worth. I'll post that elsewhere when I decide what to do.

[TheSteve]

Will you trace out the serial portion of the plugin module, it does look like a DIY version of that should be possible.

[james_s]

Will you trace out the serial portion of the plugin module, it does look like a DIY version of that should be possible.

Yeah that's the plan, it's probably not worth replicating the whole thing but the serial part looks like nothing more than a level shifter and possibly a buffer.

[tautech]

Nice adventure, result and write up James ! 

[james_s]

In case anyone cares, I took a look at my notes today and the power-on hours are simply stored as the number of minutes in hex format in locations x7E0 through x7E4 in the DS1742W. I'm not sure why this wasn't immediately obvious to me last night, I guess I was tired.

[james_s]

The comm module arrived today and I was able to use the GPIB interface to easily set the model to TDS3054. After that it showed a DC offset so I ran the SPC routine which passed and took care of that, then I connected my pulser to verify the bandwidth and this confirms a substantial improvement relative to the reference waveform I saved prior to the upgrade. With this done I updated the firmware to 3.41 necessitating another SPC and now it's all good to go. I'm a bit surprised there are still so many lesser models that have not been upgraded to 500MHz given it's so trivially easy to do.

I do intend to reverse engineer the serial portion of the comm module, it might be a few weeks before I have time to dig into that though.

[james_s]

After working fine for a while my repaired DS1742W crapped out. It would still function fine with the scope on but every time I shut it off the memory and time get randomly corrupted. The battery is fine and still connected, after messing around with it for a while I suspect the power controller IC inside it has failed, perhaps it was damaged accidentally with 5V from the programmer.

After scouring datasheets I found the still current DS1744 which appears to be identical except for being a 32k part vs 2k. It is also available in a PowerCap package instead of the ridiculous potted battery. If I tie the top four address lines high this should get me something equivalent to the DS1742W. I whipped up a quick adapter board this afternoon, once I've built and tested one I'll post the files.

[ArcticGeek]

James,

I think your solution sounds pretty good.   There are a couple other options that I considered but haven't been motivated enough to try yet:

1.  A small interposer board that has male pins on one side (24 pins) and a female socket on the other for a 28 pin DS1744W part.  The DS1744W is still available, and tying the upper address pins would work fine.   The only problem with this approach is the DS1744W part is going to be sitting roughly ~3/8" higher above the board due to the height of the sockets/headers.  I don't know if this is a problem or not in a TDS3000 series scope, I haven't checked the Z height constraints.   The other issue is that in another 15 years or so you'll be stuck finding a replacement for DS1744W because its battery will be dead too, and that part might be obsolete by then.

2.  A small interposer board that has male pins on 1 side (24 pins) and a discrete version of a RTC clock/cal and NVRAM.  From what I can tell, a DS1558 would be a compatible RTC and NVRAM controller....and then you would add a 2K SRAM, a 32Khz crystal, and a coincell battery.   This would have the advantage that you could change the battery down the road should it ever expire and you would not have to worry about it becoming obsolete.  It also would not be as tall as #1 above.  The disadvantage is the design is more complex.

[james_s]

I briefly considered the first option, then decided I don't want to invest money in another stupid potted block, I'd just be dealing with it again 20 years from now when the parts are even more hopelessly obsolete niche items. Height would also be an issue as you suspect, the housing for the rear accessory port where the comm module, DSI interface or printer install only clears one side of the (socketed) DS1742 by about 1/8" so an offset adapter would be necessary. Given this constraint and my dislike for the potted battery, the surface mount PowerCap package seemed like the obvious choice, even if the replacement PowerCap becomes obsolete it's not potted so I can easily hack a new battery into it later.

I also like option 2 and considered that as well, I came across the DS1744p before locating a suitable RTC though. I may design something around the DS1558 just for giggles, I would not be the least bit surprised if that's what lies within the DS1742 and related parts. I know from x-raying similar Dallas bricks that they contain off the shelf ICs which are almost certainly Dallas' own offerings. The DS1386 for example has a large QFP that may well be a DS1588. The limiting factor in the imaging of these is in digitizing the film as I lack a proper film scanner.

[james_s]

DS1558 won't work, the register map is different, it has a lot more features and some things are moved around. Maybe there is another similar part that is the same as used in the DS174x parts.

[james_s]

In retrospect I should have xrayed the virgin DS1742W before I hacked out the dead battery. Anyone got a dead one that hasn't been hacked up? Doesn't *really* matter but it would be cool to add that to the collection of images of these things.

[2N3055]

How about M48T12 ?

[james_s]

It's 5V only so it wouldn't work in these scopes. If someone wants to send me one I'm happy to xray it though.

[ArcticGeek]

DS1558 won't work, the register map is different, it has a lot more features and some things are moved around. Maybe there is another similar part that is the same as used in the DS174x parts.

@James
Yea, I was aware of the difference between the DS1742 and DS1558, but I believe it will still work.  You will notice that address range XXX8 thru XXXF are identical between the two parts, its just that the DS1558 has some extra regs from 0 thru 7.  Since the DS1558 has a full 512K of address space and the SRAM is only 2K, you can play a trick on the address bits of the DS1558 to fool it.  The DS1558 will forward the chip select to the SRAM only if the address lies outside of the range of 0-F.  If the address lies within the FFFFF0 and FFFFFF range then the DS1558 does not assert CS to the SRAM and it responds on the bus.

I believe the following trick will work:

The address pins A[0:10] of the SRAM are wired to the scope address pins A[0:10] as they should be.

Address pins A[0:2] of the DS1558 are wired as they should be to pins A[0:2] of the scope address bus.  Address pin A3 of the DS1558 would be tied high to 5V.  Addr A[4:10] of the DS1558 is connected to A[4:10] of the scope as well.   But address pin A11 (or any other higher address for that matter) of the DS1558 is connected to A3 of the scope.  In this way, anytime A3 is low (such is the case in address range 0-7), the DS1558 will not recognize it as a valid range for it to respond on the bus and will forward the chip select to the SRAM.  All of the other address bits of the DS1558 would need to be tied high to 5v. 

Doing it this way, the DS1558 would respond on the bus anytime the address was in range of 7F8-7FF, and its register map would be identical to the DS1742.  However, when the scope accesses address range 7F0-7F7 the DS1558 would see this address as 7FFE8-7FFEF and would not respond on the bus and forward the CS to the SRAM.  This would have the effect of making the memory map of the DS1558 identical to the original DS1742.
The DS1558 regs at 7FFF0-7FFF7 are never accessible, but that's okay because they'll never be used anyway.

I haven't looked at this in super detail, but I'm fairly sure it would work.  I hope my explanation makes sense!

[james_s]

Hmm ok so looking over these maps again, they're *almost* identical except for one thing, BF the battery flag is at 7FC on the DS1742 and 7FFF3 in the DS1558. In this particular application I don't think that matters since as far as I know these scopes never look at the battery status. I might have to build something at some point just to see if it would work, I looked around and it seems the DS1558 is the only similar standalone RTC IC that they still make.

I've also pondered various solutions with a CPLD or small FPGA which could easily do any kind of address translation desired and it should also be possible to interface a modern serial RTC to the bytewide format. It might even work to use a serial FRAM based EEPROM combined with block RAM in the FPGA to eliminate the need for the SRAM and battery management.

I wonder if the still available TDS3054C still uses the same obsolete timekeeping RAM?

[ArcticGeek]

Yea, I had noticed the battery flag as well, but I would be very surprised if that bit is ever looked at in the Tek firmware.

To answer your question about the TDS3054C, yes, I believe it probably has the exact same DS1742W part.  I have a TDS3014C and it has the DS1742W part.  I haven't replace it yet, but as I recall it is getting close to the 10-year mark and will be due for replacement fairly soon.

[james_s]

Well this scope is fairly old, the DS1742 was date stamped '99 IIRC so you might still have some time. Mine was dead enough that the RTC wouldn't keep time but the RAM would hold its contents, that surprised me since the battery measured 0.6V. Anyway assuming my adapter works I'll send you one of the boards if you want, I had to get 5 of them and I'm unlikely to ever need more than one. I believe the DS1742W went out of production in 2018 which makes me wonder if Tek is still manufacturing these scopes or just selling existing stock. I was a bit shocked to see they still retail for over $20k new. That's a lot of money for something with a 10 year time bomb soldered to the mainboard.

Or you can of course just hack in a new battery, just don't use a programmer that will give the thing 5V to dump the contents. I'm thinking I'll just make up an adapter so I can use the switches, buttons and displays on one of my FPGA dev boards to just hand program the 4 bytes that store the on-hours. Everything else can be set through the menu in the scope.

[ArcticGeek]

Yes, I would definitely be interested in getting one of your PCBs when you get them.   I'll send you a PM for the details - thanks much!

My TDS3014C is fairly old now, too, maybe around 10 years old I'm guessing.   I bought it on Ebay about 5 years ago and it wasn't new then.   I agree that $20K for a TDS3054C today would be a bit of a ripoff, these scopes are great for hobbyist use but a bit long in the tooth for professional use.   I don't know why Tek continues to use these Dallas/Maxim RTC chips that aren't replaceable.  They started to use them in the 2465B scopes and have continued since then.   I haven't opened any of their brand new scopes, but I know that even the higher end TDS5104 and TDS7104 used these things.

[techman-001]

I don't know why Tek continues to use these Dallas/Maxim RTC chips that aren't replaceable.  They started to use them in the 2465B scopes and have continued since then.   I haven't opened any of their brand new scopes, but I know that even the higher end TDS5104 and TDS7104 used these things.

This thread had me worried, then I remembered the scope I use everyday is made by HP (54601A HP DSO circa 1994) , and has no Dallas/Maxim RTC chip in it

I'm pretty sure my only other scope, a Tek 7000 series mainframe doesn't have one either ;-)

[james_s]

I remember thinking years ago that the Dallas chips seemed like a neat idea, this was after spending a lot of time cleaning up huge messes caused by leaking NiCd memory backup batteries on 80s arcade boards and vintage computers. I've also seen a number of computers completely destroyed by leaking lithium thionyl chloride batteries however it's very rare that I've ever seen a lithium coin cell leak and when it has happened the damage was localized to the battery holder. Anyway in retrospect it's an idiotic idea to pot a battery inside a module, just use a battery type that is not prone to leaking!

In case anyone else is interested, I reverse engineered the serial portion of the TDS3GV comm module, there was already another thread on that which I'll link here rather than fragmenting information all over.

https://www.eevblog.com/forum/testgear/reverse-engineering-tektronix-tds3gv-module-for-tds3000-series-oscilloscopes/new/#new

[ArcticGeek]

There are some benefits of using these encapsulated RTC modules.  Obviously, one benefit is that design is relatively simple compared to the added complexity of having a battery, holder, RTC, and SRAM. 

But another benefit is guaranteed battery life.  You would be surprised how poor the battery life of a NVRAM/RTC can be if the PCB is not completely clean of any type of flux residue/contamination. 

I worked on a project some 20 years ago where I designed a custom Intel 386/486 computer platform, and that design used a Dallas RTC chip with an external lithium battery.  As I recall the normal battery current was in the 200nA range; this would yield at least a 12 year life for the product.  However, many boards failed early due to the battery being exhausted, and analysis found that the battery current on those failing cards was in the 20-50uA range - nearly 200 times the current!   It was all caused be boards that were not perfectly clean, but yet even under the microscope they looked good and clean.  The circuit itself was fairly simple, but yet just a little bit on uncleanliness caused dramatic reduction.  it took quite a bit of effort to get the card supplier to keep the process in control.   The lesson I learned from this is you have to be very careful on these sub-uA circuits to make sure you keep stuff very clean.   

Using an encapsulated module gets rid of any of these issues, and I can kinda understand how Tek sees the advantage of using them.

[texaspyro]

The lesson I learned from this is you have to be very careful on these sub-uA circuits to make sure you keep stuff very clean.   

One thing that is often overlooked is handling of watch batteries.  A finger print across the edge of the cell can cause the battery to drain rather rapidly.   Never handle the batteries with bare hands!   Also, it can help to first clean the cells with alcohol.

[james_s]

I think the PowerCap arrangement is a much better design though. One type of PowerCap can work with any number of RTC/NVRAM types, it's a lot more economical than keeping a whole selection of old products in production that all have a use-by date due to the encapsulated battery.

Also I'd much rather have a battery that doesn't last as long as it should than an instrument that needs to be sent in for an expensive repair. I mean Tek didn't even socket the part, clearly they did not intend it to be field replaced and 10 years is not all that long of a life for such an expensive piece of equipment.

[james_s]

So I'm still waiting for my boards to arrive from JLC PCB so no movement there. I do however have some other stuff to share that some might find interesting. I decided to play with the DS1742W and threw together an adapter to connect it to one of my FPGA boards. The FPGA is not really doing much other than serving as a patch panel to conveniently route the switches and buttons as well as provide decoded hex displays. This shows selected address, byte to be written, and byte read with the byte read also shown on the red LEDs, convenient for manipulating individual bits.

So I started poking at the DS1742 while referring to the datasheet, I have a much easier time understanding something if I can actually see and touch it vs just studying the datasheet. Anyway I figured out why I've had difficulty programming these things in conventional EPROM programmers, it turns out that in order to modify any of the clock related registers you must first write a '1' into the 'W' bit of the control register, otherwise they are read-only. By default (with a dead/missing battery) it also seems to power up with frequency test enabled, this causes bit 0 of the seconds output to toggle at 512Hz which can cause strange behavior if it gets enabled by mistake. The DS1642 used in the TDS300 series has the same feature and it causes the displayed time to jump around erratically. Anyway I thought this was pretty cool stuff, I can hand program it, setting the time and date and watch the clock run and a setup like this is fully adequate for setting specific bytes like the power-on hours of the scope, no EPROM programmer needed and very little chance of anything getting accidentally corrupted.

As I was messing with this I happened to be looking at the status register when I bumped the DS1744 and the battery flag LED came on! Additional poking revealed that the fault that set me down the road of building a replacement DS1742W is actually a cracked joint down under the epoxy where the nickel strip that connected the original battery is soldered to the PCB. This means I should be able to repair it easily enough and that would have saved me 60 bucks. Since I already bought the parts I'm going to continue down the path of building a replacement and assuming that works I'll share the design so others can use it and keep the original DS1742W as a spare.

Incidentally the PowerCap version of the DS1744 arrived and it is a bare un-potted PCB with a commodity SRAM and DS1744D TQFP IC on the bottom. I don't think Maxim sells the bare DS1748D but it must be exactly what is in the currently made potted versions as well. Wish I could just buy that IC and build a direct fit DS1742W module.

Something else I think might be interesting to do at some point is further reverse engineer the TDS3000 and other instruments that use these NVRAMs and find out exactly what locations are used to store what. It would be very easy to wire up an FPGA board in place of the DSxxxx and use internal dual-port block RAM which can be monitored/dumped/poked live. This would be of greater interest to me on instruments like the TDS300 series that store the cal constants in the NVRAM, I have two of those and a friend has a third that all work fine but display a calibration error on power up. I was able to calibrate the voltage with difficulty but the timing calibration is too finicky for any sort of pulse generator I have access to. Perhaps it would be simpler to disassemble the firmware and attack it from the other direction, I don't know, I'm more of a hardware guy.

[james_s]

Finally got the boards I ordered from JLC PCB and built the adapter today. I'm pleased to report that it worked perfectly right off the bat, just plug it in and go. After verifying that it worked, I used the FPGA board I was playing with before to set the power-on hours and now it's buttoned up and finished.

Adapter board gerbers and design files here:
https://github.com/james10952001/DS1744WP-to-DS1742W-adapter

This should work for any application of the DS1742W however you'll want to verify the mechanical fit if you are wanting to use it in anything other than a TDS3000.

[giosif]

Congrats on your work and thank you for sharing with everyone else here!

[ArcticGeek]

Nice work - glad to see that it worked right out of box!  Thanks for sharing with the community.

[daveyk]

Hello James.  Do you have any extra boards that you had made up that you would sell?

Dave

[analogRF]

In case anyone cares, I took a look at my notes today and the power-on hours are simply stored as the number of minutes in hex format in locations x7E0 through x7E4 in the DS1742W. I'm not sure why this wasn't immediately obvious to me last night, I guess I was tired.

what about the number of power cycles? I think it must be sitting in this chip because when I lost the data on mine (3054B) that value also got lost

[james_s]

No, not in the non-letter series at least, I don't have a B series to check. My power-on count remained after replacing the NVRAM.

[Kodim]

Known issue. In my TDS3054, the lithium battery in the DS1742 chip died. As I understand it, there are two ways to solve this problem. Replacing the old battery mechanically in the original DS1742 and making an adapter for the DS1744. I do not have a programmer. Can I perform any of these operations without a programmer? Thanks.

[james_s]

Yes you can do either one. The only thing you need a programmer for is if you want to retain the power-on hours, though I suspect there is a way to write this via GPIB.

If you power on the scope while holding down a button (B Trig I think?) it will initialize a blank NVRAM.

[Kodim]

James, your comments helped me rebuild my TDS3054 oscilloscope. I remove old battery from the DS1742W chip and install an external battery. I did not use the programmer. Operating time was  not reset. Everything is fine! Thanks!

[giosif]

Just wanted to thank James, as well as the other contributors, for the nicely detailed repair and mods here, as I just brought a seemingly dead TDS 3034B back to life.
The culprit? The same 75.757 MHz crystal which had stopped oscillating.
New replacement crystal ordered (currently using a 50 MHz one I happened to have in the spares box).

Now, on to the next issues: acquisition test fails and channels 3 and 4 seem to be "linked" with each other (i.e. if I feed signal straight into channel 4, I don't get any waveform displayed for channel 4; if I feed the signal into channel 3, I get the same trace displayed for both channels 3 and 4).

[james_s]

That's an odd one, there must be some kind of mux? Hopefully it's not inside one of the ASICs.

[giosif]

I suspect the same, but I need to do more investigations.
Will report back any findings.

[james_s]

Put the proper oscillator in there first before you expend TOO much effort. I doubt that's the issue here but it's not impossible. When I put the 27MHz oscillator in mine for testing it booted up but it was not usable. It's possible that the multiplexing is dependent on the timing.

[giosif]

That did cross my mind but, then, strange it would happen only with channel 4.
As you say, it's unlikely that is the culprit but I'll check once I've installed the correct crystal.

From another perspective, I was wondering how it could happen that signal fed into channel 3 shows up for channel 4 as well.
From an analog input perspective, it can't happen, since each channel is independent all the way to the ADC, including.
From a digital point of view, the ADC shouldn't matter (as in, whether it is working or not), since each channel has their own.
So, the problem must be with storing/retrieving the waveform data to/from memory.
Specifically, I'm thinking that maybe one address line might be stuck either high or low and, whenever the memory range for channel 4 is being addressed, it ends up accessing the memory for channel 3.

[james_s]

Does each channel have its own ADC? There is so little documentation available for these scopes that I actually know very little about the architecture. IIRC they use some sort of CCD technology for the capture memory but I don't know offhand where the separate channels converge.

[giosif]

Well, that is my novice level of understanding & of describing the scope functionality.
Whether those ADG361D ICs are really ADCs or something else, I actually don't know, but those are the ICs I was referring to.
So, since each of the other IC types nearby are in a quantity of less than 4 (to match the number of channels), I suspect the issue might be with one of those, rather than the ADG361D on channel 4 or anything below that ("below" = towards the input terminal).
But this is just me trying to make sense of the behavior I'm seeing, without a solid understanding of scope functionality or inner workings of this particular model.

[giosif]

Today, I had a look at the thermal image inside the scope while it was on and I could see the "ADC" IC for channel 4 (aka U400) stays cold, while all others are getting hot.
So, something is definitely wrong on that channel.
I want to check if U400 at least gets power, but let's see if I can find the right pins (a datasheet would be good now).
I will also ask on the forum for anyone with a spare ADG361D they would like to sell.

[james_s]

Can you find any decoupling capacitors in the vicinity? That's usually a good place to start for finding the voltage to an IC. I'm more inclined to suspect that the chip is not getting enabled rather than not getting power though. Since you're getting data from another channel instead that implies that the same DAC is getting enabled instead of the one you want. It's been a while now since I've poked around inside one of these but look for something like a 74LS138.

[giosif]

There are several caps on the other side of the board (see picture), and only one tantalum on the same side (and doesn't appear to be related to the power rails for the "ADC" ICs).
In terms of ICs in that area of the board other than the ADGxxx ones and processor & memory, I can only see an Elantec 4581CS "sync separator" (quoting from the data sheet, as I don't really know what that means) and an MC33178 op-amp.

As a side note, while investigating the board, I noticed resistor R555 (inside the red rectangle in the attached picture) doesn't have any markings and looks kind of suspicious to me.
Measuring it in-circuit gives me a reading of approx 39 kOhm.
It's a long shot, but anyone here happening to have a similar board at hand that could check the value of that resistor, please?

[james_s]

Sync separator ICs do exactly what the name implies, they take a composite analog video signal and separate out the horizontal and vertical sync signals. In the scope it will be used for the video triggering option, not hugely useful for most people anymore but it was very handy in a former job where I often used a TDS3000 to look at the Macrovision analog copy protection pulses on the analog video outputs of the settop boxes we made. Macrovision used a series of pulses in the blanking interval of several specific video lines to upset the AGC in VCRs to prevent recording protected content and the TDS3000 with that option could trigger on a specific video line.

We also had a few Tek VM700's that were much more capable  in terms of measuring analog video signals however they were limited to 480i standard definition. Not that any of this helps you fix your scope.

I see nothing particularly suspicious about that resistor and 39k is not an unreasonable value for a resistor but I suppose it can't hurt to compare it. I really think the problem is going to be with the address decoding logic that enables the DACs or whatever those are. How that is actually implemented in these I have no idea, it would be fantastic to fully reverse engineer these scopes at some point.

[giosif]

Thank you for the info and apologies for not responding up to now!
I've been waiting for a replacement oscillator I ordered to show up, but over a month later and still no joy.

In the meantime, I've tested the non-working oscillator and it behaved exactly like in your case: it won't do anything for supply voltages above 3.3V but, at about 1.7-2.0V, it would start oscillating at 25.25 MHz.
Afterwards, I decided to have a look inside (see attached pictures).

[james_s]

That's interesting that they both failed in exactly the same way.

While you're waiting, I suspect an oscillator that is approximately the right frequency would probably work ok at least temporarily. Can you find anything in the 70-80MHz range locally? My scope actually booted up with a 27 MHz oscillator, it wasn't usable but something that is at least in the right ballpark might work. I actually have a spare oscillator as I bought two at the time I ordered it, but as I'm in the US I doubt I could get it to you any faster than the one you already ordered. Some mail is very slow these days, I ordered some small parts from Australia that took over 2 months to arrive.

[giosif]

I have already fitted an oscillator that I had - it is running at 50 MHz.
Maybe trying something closer to the 75.75 MHz would be a good test to see if channel 4 would start working properly then.
However, I am not that keen to swap oscillators on the board, in fear I may damage something else.
So, I think I'll wait for the right part to arrive.
Hopefully sooner than 2 months...

[giosif]

Just a quick update: the oscillators I've been waiting for all this time have finally arrived (would have one to spare, in case someone UK/EU-based needs it). 
Installed one in the scope, fired it up and checked channel 4 - the problem persists (signal from channel 3 input replicated on channel 4, no signal from the actual channel 4 input). 

Another issue I had noticed before, but wasn't sure whether it may be due to the wrong frequency of the oscillator (the temporary one was running at 50 MHz) - Ethernet connectivity was not working.
This problem continues to be present even after installing the correct type of oscillator.
Some details: when connecting the Ethernet cable, the link on the switch port comes up (at 10 Mbps, half-duplex), but there is no traffic coming in from the scope (used static IP config on the scope).
I even tried manually entering the MAC address into the switch MAC address table, as well as a manual ARP entry for the IP of the scope, but still no joy.
I checked connectivity between the board with the Ethernet connector and the main board and all seems to be in place.
I'm stating to think whether the main CPU might have some issues...

[james_s]

It's possible of course, but virtually every time I have suspected some expensive, difficult to test and difficult to replace part that has turned out to not be the case. Given the scope mostly works, the CPU itself is one of the last things I'd suspect.

[giosif]

I get what you are saying but, then, for the Ethernet not to be working...
As far as I can tell, the network data goes from the board with the Ethernet connector straight to the main CPU.
Of course, there is the possibility something is broken on the board with the Ethernet connector but, to the degree I could check it (it can be easily powered outside the scope), all seemed ok with it.
(Also, forgot to mention on Ethernet troubleshooting, I tried both straight and crossover UTP cables).

The above said, I will for now treat the two main issues as unrelated and for the fault with the network connectivity as unlikely to be caused by a broken CPU.
Need to think of next steps to troubleshoot the network connectivity problem...

[james_s]

It could be something with the address decoding to select peripherals, that could break ethernet and one of the channels depending on how the address is laid out. It could be a fault in the ROM or RAM, it could be two completely unrelated faults, there are many different things it could be. Is the CPU address bus buffered or do address likes from the CPU connect directly from the CPU itself to the expansion connector? Given the way computers work, a fault in the CPU will normally cause much more serious problems, if an address like is stuck then large swaths of memory and IO will be inaccessible, if any of the lines on the data bus are not functioning then almost nothing will work properly.

[Galen]

My TDS3014B and 3012B, all can't make Ethernet work. Using  crossover cable, The computer said "connected, but I ping the scope, no reply.  The scope looks good for all other functions, only the network, always fail, even I fix the IP at both side. no clue what's wrong.

[madao]

spare parts  TDS3012 is arrivied  for  repair of gosif's  TDS3014B and my  TDS3014.

Sad,   only PSU is dead,   it runs good with  external  15V .  SPC  passed.
I make  think about it...

greetings
matt

[Galen]

spare parts  TDS3012 is arrivied  for  repair of gosif's  TDS3014B and my  TDS3014.

Sad,   only PSU is dead,   it runs good with  external  15V .  SPC  passed.
I make  think about it...

greetings
matt

For the PSU, 3 resisters are very high temperature,especially the 2 serial connected near the transfomer at the board edge.  Does one of them open circuit?

[Galen]

I added a heat sink to the two resisters.
circled the 3 resisters in below picture.

[madao]

your PSU look bit other than my PSU.

But your tip is  good.  Not big resistor in Pictures, small  brigded two resistor is open.  (2x  390 kohm series, your have probably  one 820k, near primary eletrolytics, hidden by  blue ceramic capacitor)
PSU lives again.

Thanks.
Next step: desolder  NVSRAM, battery is empty.

Greetings
matt

[giosif]

Was looking inside the scope again this morning and noticed something I hadn't before: is it just me or the flex cable going from the Ethernet board to the main board is awfully close to those two resistors that are known to get toasty when the scope if turned off (see pictures)?

Now, I have done a continuity check on that flex cable as part of my initial troubleshooting, and all checked ok then, but that was with the cable outside the scope, sitting on a flat surface.
I wonder...

[Galen]

giosif, not only you.   I got 3 TDS3000B recently, the flex cable are all like that. I have to bend this cable to make a little space from the 2 hot resisters.

For the Ethernet, both my two 3000B fail to connect with computer, even I use cross over cable and fix ip at both end. strange. I have no clue.  waiting for your finding.

[Galen]

My third TDS3000B, acquired as dead machine, blank screen, no response to any key.  I guess this is very possible caused by the oscillator. So I bought them. when I measure the out put of the crystal out put, no signal. My normal TDS3012B has 75.757M output. so definitely, this oscillator is dead. then I found it was soldered in wrong direction. check the other oscillator (48M), wrongly installed as well. and both frequency are wrong. 
I bought 2 oscillators and they arrived today. replaced the wrong oscillators. power on the scope, wooo, it boot up normally!
Then I do some measurements. it functins well.
But, it always has a but, I can't find a 75.7575 oscillator, now using a75M, it works well. only the frequency measurement reading is a little wrong, for the 1K square wave, it shows 1.010K.  This is obviously because of the 75M oscillator.
Now I need to find the strange frequency 75.757 oscillator.
BTW, this scope also missed the handle anchor assembly, and the trigger level potentiometer broken. Will try to repair them.
Anyway, already a happy success.  it's time to have a beer.

[AlcidePiR2]

Anyway I desoldered the chip and installed a socket, then popped it in my TL866 and read it as an EEPROM saving the contents to a file.

hi James

Which setting ( which chip) did you use for the reading of the DS1742 on the TL866 ?

Thanks

[madao]

Anyway I desoldered the chip and installed a socket, then popped it in my TL866 and read it as an EEPROM saving the contents to a file.

hi James

Which setting ( which chip) did you use for the reading of the DS1742 on the TL866 ?

Thanks

DS1220 Setting  (both is  2k x8 NVSRAM, which  DS1742 has included  timekeeper.)

[AlcidePiR2]

This is what I did, but  I had an error message when I try to read.

Now I have tried again and realized my mistake.  I had not properly mounted the device. Now everything is fine .

I have attached the .hex file here

I hope this is fine.

I still have two questions :

- Is there a way to know the level of the battery without opening the case ?
- Where can I find a picture of the inside to know where to drill if I want to hook some wires and external battery ?

Thanks

[giosif]

Was looking inside the scope again this morning and noticed something I hadn't before: is it just me or the flex cable going from the Ethernet board to the main board is awfully close to those two resistors that are known to get toasty when the scope if turned off (see pictures)?

Now, I have done a continuity check on that flex cable as part of my initial troubleshooting, and all checked ok then, but that was with the cable outside the scope, sitting on a flat surface.
I wonder...

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!

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

[Maxis]

Hello Sicco!

Thank you for your detailed reply!

I would use your board with the pleasure, but I'd like to do my learning kinda hands on the project.
There are a few points which are not quite clear yet:

1. As you have kindly explained - the information in the Dallas chip is vital for proper Ethernet functioning.
But the question is - how these bytes made its way into the Dallas at the first place?
Normally if I just borrow TDS3EM from someone it will work straight away, right? If so, then I can assume that beforehand I can check whether the settings are correct with the stock TDS3EM and only then use your baseline schematics.
Also what I know there is no need in "harmonizing" Dallas prior to installation of TDS3EM module. Otherwise Tek would supply the floppy with the specific license installer to perform Dallas NVRAM "harmonization" (often this is how it's done on Agilent equipment).
If all the above fails with the stock TDS3EM, then I can assume that the NVRAM is corrupted and then I need to use your NVRAM image, right?

2. You have mentioned that I can use the BDM port to program. By looking at the connector pinout on your schematics I've got to use not only JTAG lines (TCK, TDO, TDI + Hard Reset + Soft Reset + IRQ6), but also I need to connect the TXD_SM and RXD_SM UART lines, right? Cause as you mentioned all the FW debug messages are communicated via the UART SM port.

3. The option module already has everything loaded thanks to the awesome contributors of this forum! However, I wonder how do you get a transparent access to the devices connected to PowerQuicc via BDM. Do you need to load a debug portion of the code into PowerQuicc prior to it, or BDM uses the bit-banging protocol like in the case of JTAG? Have you developed the tools to emulate the bus access via PowerQuicc pins or you used the standard facilities of the BDM debugger?

Thank you very much for your help!

[sicco]

Maxis,

If you plug in a working borrowed-from-someone- TDS3EM then your TDS3000 may or may not work. If the scope’s NVRAM no longer has its original ex-factory ethernet config bytes properly set then it (ethernet) will not work. A dead battery in the NVRAM means original settings data is lost.

To get the NVRAM reloaded with a working image, it’s either eject from a DIP 24 socket (which i envision you have by now) or desolder the DIP24 DS1742W and use an old EPROM programmer, or use BDM. There might be utilities using floppy disks, maybe serial port backdoors, but i’m unaware of those.

The BDM port is explained in some detail in the NXP datasheet / XPC8xx user manual. It shares some but not all of the JTAG pins. The serial port (UART1 or 2) is not needed. But BDM is a legacy. Initially JTAG was for testing hardware pins, while BDM was for in circuit debugging. Nowadays JTAG is for everything. But not yet on this CPU. BDM for this CPU is more about pushing opcodes into the CPU that the PowerPC then executes, single step, when halted. Hardware needed for BDM to USB to PC is just an FTDI2232 or FT4232 with its eprom, xtal etc. Software is a lot more...

[Maxis]

Hello Sicco,

Thank you for clarifying the subject. In my scope the NVRAM is still alive and kicking. So, I'll try with its stock content hoping that everything will work w/o its reprogramming. I'll post here any updates on this subject!

[james_s]

Surely there's a way to write to the NVRAM using GPIB or serial commands? Of course you'd have to know the address where the relevant info is stored.

[SMdude]

Hi Guys,

Does anybody have any info on the battery gas gauge used in the li-ion packs?
After buying one from ebay and having it confiscated by the "global shipping program" (yes I got a full refund, but I still don't have a battery!) I have now resigned to the fact that I will just have to build a battery for it instead. So it would be nice for completeness sake if the fuel gauge would work. I'll probably start a new thread for it in the coming weeks, just trying to gather as much info in the mean time.
Looking at the available space a 4s3p pack/setup will fit nicely with room for the protection cct and charger board.
Housing will be 3d printed.

Any photos or info would be greatly appreciated.

Cheers

[rauldm]

I changed battery to nvram in a TDS3014b, ethernet configuration is not work today, i clear nvram with trig b and I go to devel mode with select button to start, this cleared hours, power on counter and errors, but ethernet still Is not working.

[sicco]

That’s consistent with what i wrote in my earlier posts in March. It can be fixed. Load the binary images as provided in those posts  into your DS1742.

The ‘TDS3000 second life light’ plugin boards that i made enable in-situ DS1742W editing from a PC over USB.
If you find my ‘second life’ boards too expensive then desolder the DS1742W NVRAM ic from the tds3014b mainboard and get an old style DIP24 eprom programmer that programs/writes 3.3V DIP24 chips like the DS1742W.

I have seen no options yet for editing the DW1742W in-situ via GPIB or RS232 or printer port.

(ps the ‘second life boards’ also have board space for a DS1744W that can take over the role of the old DS1742 that can stay on the main board - but right now you don’t need this. All you need now is an easy way to edit the DS1742 that you’ve revitalised with a new battery. The second life boards with BDM interface provide that)

[james_s]

IIRC it is possible to write to memory locations via GPIB, but I have no idea where the NVRAM sits in the address space.

[sicco]

It’s at byte address 0x02800000 of the PowerPC physical memory map. You think there’s a peek and poke for its bytes via GPIB? I’d be surprised, but maybe…

[rauldm]

Sicco, I'm from México, how can Buy your secondlife board?, I like because it has vga Port right?

[rauldm]

Can You sell in Amazon?, Amazon is very safe un México. Regards.

[james_s]

Well you can write values to change the model number to upgrade the bandwidth, I just assumed it was possible to write to other locations as well.

[sicco]

@Raulm, I have 4 boards left with only the FTDI4232 chip for USB to BDM populated. With those you can edit the DS1742W content in-situ. Or reflash the entire TDS3000 ROMs. Or use the two serial ports as USB COM ports.

These 4 boards are not 100% perfect yet: without a PC connected that runs the program that I attach here, it blocks booting of the scope after a power on. That's because without initialisation, the FTDI4232 chip that I use forces a BDM pin high that normally is pulled low when its not connected... Should not be a problem for you because I'd expect you only use the board to edit what's in your DS1742W, and then unplug it again.

Here's how you'd use it:
1. Insert in the board in the scope expansion connector, components side of the board facing down (important!).   
2. Wire micro USB cable to Windows PC, PC powered on.
3. Power on the scope. It will give a white screen, because the CPU is held in waiting for BDM mode (as per problem/hardware bug mentioned above).
4. Run from command prompt the utility BDM.EXE (it's in the zip attached, under \bin\Release - but C source code is in the zip. It's a Code::Blocks project).
5. If FTDI drivers are OK, then tool finds the FT4232H chip, senses the PowerPC CPU and tells you what it sees as DS1742W chip, battery status, and gives a menu of options after you hit <enter>.
6. The TDS3000 will boot up normally after you type H (capital h). That's a hard reset for the PowerPC.
7. Quit (type q) and restart the BDM.exe tool.
8. First thing to do: back up your flash ROM, back up your NVRAM. That's option r for the ROMs and when it's done with that (~5 minutes), pick option c for the NVRAM. You get a time/date stamp in the .BIN file names that it makes for you.
9. To overwrite the NVRAM, copy the binary data that you want in it to a file named tekRTC_DS1742W.bin and pick option w. The default one that's in the zip does correct your Ethernet issue.

Overwriting the entire flash ROMs (say you have a v3.41 firmware in a TDS3014, so with only 100 MHz scope bandwidth, but would prefer your scope to behave as a TDS3054 with 500 MHz bandwidth) then then tool allows you to do so, in a bit more brute force way then the BULLDOG trick over its serial or GPIB port. This should work for the newer -c TDS3000 models also, but I have not had the opportunity to try it out. Also I do not have those rom images yet.

Likewise, if you'd like to have your option module(s) edited to TDS3ENG, then the tool can do so for you with the option modules in-place in the front/side panel.

Check first if you can run this code at your end. So without a USB plugged in. Because if not then there's no point shipping boards...
Finally, no need necessarily to use 'my' boards, you can also get a 'FTDT2232H mini module' and manually solder the 7 or so BDM wires on the 100 pins main board connector. 

[rauldm]

I found in other post, the serial port I think is uart level because original tds modules comes with uart-rs232 IC, is located on
68 TxD
69 RxD
70 RTS
71 CTS
from expansion connector, with BDM.exe program and uart USB converter can be program the NVRAM?

[rauldm]

I read more about topic, the FT2232H is for access with JTAG, I hacked my oscilloscope because is coming with old firmware, after, I updated to 3.41 and change the floppy for USB emulator, I like ethernet interface for get images to PC, but I think only work with USB now. I hope find a FT2232H. I have also the TDS3ENG, I programed an eeprom that I got from old ram memmory, I wrote it with Arduino. I have two tds, 3012b and 3014b, first is only 800 hours and still works the NVRAM battery, I got the 3014b with 11000 hours, the battery was near to dead, but still kept SPC constants and some settings, each reboot I lost the backlight setting and time/date.

[sicco]

[ Specified attachment is not available ]Raulm, you're on the right track I think. Just to clarify a bit more: the FTDI USB chips are generic units that can be used as UARTs, or as JTAG, or as BDM ports. Or I2C or SPI or whatever. Or as a mix thereof. The FT2232H has two 8 bits ports, the FT4232H has 4. So if you have two serial ports and a BDM port, and want to use them all at the same time, then the FT4232H is the best choice. For now I think you only need the BDM function with maybe one serial port (because you like to copy screen dumps to your PC?).

JTAG is irrelevant here even though the legacy PowerPC CPU XPC860 has JTAG, you cannot really use it in a TDS3000 because there's a pin for it (TMOD) soldered to a power supply rail, right under the BGA, so pretty much impossible to cut that line. But the BDM (a legacy Motorola/Freescale/NXP backdoor debug port, somewhat like JTAG but not quite...) interface does has its pins wired to the expansion connector. So that we use. As per the schematics shared in this forum, but here it is again in pdf attached. Be aware of different styles for pin numbering - that's because it's a PCB edge connector in this design, not the official 100 pin Molex connector.

Besides BDM, the TDS3000 100 pin expansion connector has two TTL level serial ports. One is without CTS/RTS handshake lines and is a VxWorks monitoring / ex factory testing line, the other is the serial (RS232) port that's on user i/o modules like TDS3VM and others. The latter is what you listed. It's also the port for a serial printer and for https://www.eevblog.com/forum/testgear/tds-1000-2000-3000-bw-hack/. That's a hack at application level. The BDM port is about diving at a much lower, deeper level, peeking and poking right into the hardware, halting and single stepping the PowerPC CPU. Or reflashing the ROMs. Or peeking into the other i/o on board. Or pinging its I2C bus that goes to the front panel.

If for you it's only about editing the NVRAM via BDM, then you don't need any of these serial ports now. Just BDM.

The relevant pins for BDM are: TDO, TDI, TCK, SRST, HRST, IRQ6 and GND. Those go to a MAASP port on the FTDI chip. The program I shared assumes you wire the 8 TTL level bidirectional I/O lines from either a FT2232H or a FT4232H, like this:
ABUS0 -> TCK
ABUS1 -> TDI
ABUS2 -> TDO
ABUS3 -> not used
ABUS4 -> SRST
ABUS5 -> IRQ6
ABUS6 -> HRST
ABUS7 -> not used
GND -> GND
 
Or, as it's coded in the .h file,
#define MASK_DSCK   0b00000001
#define MASK_DSDI   0b00000010
#define MASK_DSDO   0b00000100
#define MASK_SRESET 0b00010000
#define MASK_FRZ    0b00100000
#define MASK_HRESET 0b01000000
#define MASK_NEN245 0b10000000

I've mixed up naming conventions for JTAG and BDM - the XPC860 uses many of the same pins for either BDM or JTAG. But you get the idea I think.

 second_life_tds3000_light_FT4232H.pdf (320.37 kB - downloaded 187 times.)

[rauldm]

I can't to run de BDM.exe Windows says it want  libwinpthread-1.dll to run, I install codeblocks ando doesn't work too. I found also some generic FT2232H from Aliexpress looks fine.

[sicco]

The DLL missing from MinGW / gcc is a common issue. Do a quick Google search on the DLL that was missing.

See also https://stackoverflow.com/questions/18138635/mingw-exe-requires-a-few-gcc-dlls-regardless-of-the-code

I think you just need to download the DLLs and place them in same folder as where your bdm.exe is.

[rauldm]

@sicco I put DLL in same folder and works now, I will buy  a FT2232H from aliexpress. My scope rebots when I select DHCP mode in ethernet, my other oscilloscope TDS3012B can be configured in DHCP, if not is assigned IP address only I get a leyend on screen.

[Jarek]

Hello everyone
I also had a problem with the ethernet connection on my TDS3032. For me, it was helpful to connect the TP-Link WA855RE WIFI amplifier to the oscilloscope.
It was enough to log in (DHCP mode  in oscilloscope). Test conection was OK
Enter the address returned by the oscilloscope in the webb browser.

[rauldm]

Thanks Jarek, but, are you changed battery inside of NVRAM? when you changing the battery you corrupting nvram information for ethernet

[Jarek]

I did not replace the battery yet , but I could not connect to the network, only what I wrote helped.
(TDS3032B Model)

[sicco]

Oops - an error in the schematics that I shared as pdf last month: the SN74LVC245ADWR IC3 that I added in the TCK (DSCK) and TDO (DSDO) lines: forget that buffering. First error: I mixed up in and out: the second buffer should have been in the TDI line, not in TDO. Second error: the IC3 SN74LVC245ADWR appears not to have enough muscle to decently pass a logic  high level to the XPC860 CPU input which has a pull down resistor on the main board.

PS Note the ESP32 DEVKITC U1 and U9 and U10 and U11 are not needed - they are for WiFi/Bluetooth and for an attempt to restore a dead battery DS1742W via yet another trick: not adding the DS1744W U2, but instead leave and keep using the existing dead battery DS1742W but overwrite its content via the BDM interface at power on reset time, setting the clock from another RTC on this board. And then catching every write cycle over BDM with breakpoints - so let an Arduino program do all that from the EPS32 - but that was all a bit too much for now, so did not finish that.   

@Rauldm: did you get it working ok now with your AliExpress FT2232 module?

[rauldm]

Hi Sicco still doesn't arrive my package.
Regards.

[sicco]

Here's an update of my TDS3000 BDM backdoor USB FT4232 interface PC control program. With a bit of user instructions. Ping me with a PM if you want source code. I've omitted the TDS3K binary rom images in this zip - they are 4MB each and that made it too large to post here...

Plug-in board hardware details shared before in this thread - no big change there except for the fact that I decided to power all FT4232 VDD pins from the USB connector instead of partly from/by the scope.
Starting to also better understand now how the Tektronix DPO acquisition concept works and what those Micron MT 128k  SRAMs do for video display and acquisition RAMs, and where those sit in the MPC860 PPC memory map. But still frustrated that we cannot find anywhere the super secret NS datasheets anywhere for the MM9595 ADG360C ADG460C ADG365 361 etc. Anyone out there that has these?

[lecatron07]

HELLO ALL

I HAVE A TDS3034 SCOPE AND THE SCOPE IS STUCK AT THE FIRMWARE UPDATE SCREEN I TRIED FIRMWARE UPDATING IT KEEP SAYING COULDN'T READ THE FIRMWARE FROMM FLOPPY DISK
IT DOESN'T PASS THE SCREEN (IT USED TO PASS IT SOMETIMES)
IS THERE ANY WAY I CAN FIX THE PROBLEM IN THE SCOPE

[coromonadalix]

pls dont write in capital letter, it sound like  yelling  loll


an a tds3k, i had to find an used usb to floppy drive and format floppies, to be sure they where okay it created a set of floppies

[lecatron07]

hahaha .. i was excited when i was writing ..

i used a dpo7104 as a floppy writer, 4 floppy disks are ready
but the scope is not accepting them or for some reason is not reading them as in the pictures



 

[rauldm]

You can try depress and hold select key or b-trig when you turn on the scope. With select key you can access to devel menu

[sicco]

If new diskettes and a new floppy disk drive do not solve the issue, and/or,
if upgrading the 1.44" disk drive to a USB drive adapter does not solve it, then,
you might try the BDM adapter discussed extensively in this forum thread. That allows for a complete erase of the flash rom chips, and then a reprogramming of them. That will get your scope running again.

The firmware upgrade via diskettes is only modifying the application program, but keeps the VxWorks bootloader rom section as-is. The BDM backdoor adapter allows for a full wipe and re-imaging of the TDS3000 motherboard flash rom.

[lecatron07]

rauldm i tried that it doesn't boot
it stays at the update stage

sicco  i tried the floppy but i will try your BDM
i may buy a FTDI4232  board and test with your software

[sprit]

Hello, have a good day everyone.

I know this topic is quite old but I just encountered a problem and hope you can help.
I have a TDS3032B scope, after the DS1742W battery died, I tried to replace the CMOS battery for it and then I got this situation. The display is blank or stuck at the welcome screen. I don't know what's wrong with it...
I don't have a TDS3GM/GV card, I'm ordering the FT4232 controller board, it should arrive in a few days. But when looking at this pinout I got confused, does anyone know how to arrange their numbers? I don't know the location of pins 2,3,4,...etc, except for pin 1, which I guess is a square pinout like the picture. Can anyone help me? Thank you very much <3
Sincerely,

JingFeng

[picburner]

The pinout is as per the attached pic.

[sicco]

The formal pin numbering is as in the previous post.
However, the ‘budget version’ plugin board that i designed uses a different numbering convention. That’s because the budget board uses pcb edge connector instead of the https://eu.mouser.com/ProductDetail/TE-Connectivity/1-1734099-0?qs=sGAEpiMZZMvlX3nhDDO4AKFmralhIPMMK7YJ2cTxry4%3D.

PS pressing the B-Trig button while scope powers up may also reset the NVRAM to a state where boot procedure does work. But ethernet MAC address will not be restored.

[sprit]

Thank you very much <3

[sprit]

Hi Sicco. Thank you for your contributions. Hope you have a nice day.
I tried pressing the B-Trig button but everything is still the same. Looks like my DS1742 has some problem or is broken. I tried taking it apart and the scope still has the same problem-white screen or stuck on logo . Can you tell me if I can get a DS1742 from another range instead and reprogram it? I only have the RT4232 USB. Thank you very much.
Sincerely
JingFeng

[sicco]

JingFeng,

Options are:
* The james_s DS1744 adapter board.
* Replacement units such as https://www.ebay.com/itm/293776182478
* The ‘second life’ budget board that plugs into the 100 pin connector.

Advantage of the ‘second life’ board is that it gets you lots of diagnostics from a tds3000 board that does not boot ok.  It enables reading/writing the RTC data via BDM via USB. It also enables capturing of the VxWorks system boot log.

[DC_to_Light]

Looks like I am joining the party, with a TDS3054B and a DS1742W that has lost its mind.

I've extracted the DS1742W, milled away 0.030" of the top plastic to get to the battery.
The top terminal of the battery is GND and connected to package pin 12.
I used a hot soldering iron (to soften the potting compound) and various picking tools to
dig down in the area between pin 13 and the battery perimeter, till I got to the battery
positive terminal.

The positive terminal is also exposed as the shell of the battery. My battery measures
0.673 mV, and at such high impedance that my 10 MOhm/V multimeter causes the voltage
to slowly drop. I soldered a red wire to the exposed positive terminal of the battery, and
cut the negative side of the battery terminal at the point where it gets thin. Unfortunately
I had not connected the new battery yet, and lost the  "NV"RAM contents.     
Anyway, I added a CR2032, restarted the scope with B-Trig, and after warm up, successfully
ran SPC.  This passed, and the clock now keeps time reasonably accurately.
What does not work is ethernet, and I have the same issues as other people. From my
reading, it seems I need to load a valid image into the DS1742W to restore the ethernet
functionality.

1)  Is the 3054 image supplied at the end of article 99 of this thread the image I need,
     and if not, where do I get it?
2)  How do people load the image into a repaired DS1742.
     My programmer does not know about the DS1742W, but does know about the DS1220AB
     Unfortunately all versions of DS1220xx are 5V parts, so my programmer (Advin P44+)
     will set VCC to 5V, and the signal thresholds appropriately. This could destroy my DS1742W.

     A)  Is there some other suggested device that has the same pinout, but is 3.3V?

     B)  Or do I get a 3.3 V microprocessor, build an interface to a 24 pin ZIP socket, and write
           a reader/writer program, to load the image into the DS1742W

Are the locations for power cycles and operational hours known, and what are the formats.
Currently my scope is reporting that it has been turned on for  -2,147,483,648 hours

Thanks for any guidance.

Philip

[sicco]

This C code tells you where to find MAC and 'engine hours' in the DS1742W memory. Engine hours is specified in minutes. MAC is just 6 binary bytes. But they must start with 0x08, 0x00, 0x11 as that's what the firmware checks as allowed "Tektronix Inc" MAC addresses. The next three bytes: best to use a random number generator so that not all devices that we fix get the same MAC address as the one that was published as valid image in the post that you referenced.

To answer the question:

#define ENGINE_HOURS_IN_NVRAM   0x07E0 - 4 bytes uint32_t, minutes not hours
#define MAC_ADDRESS_IN_NVRAM    0x06F0 - 6 bytes
No checksums, crc's  or anything to check data integrity for these fields...

A corrupted / erased DS1742W can be reloaded in situ via the BDM interface (100 pin expansion port plugin) module and PC software for that. I have a few boards left at present. 100 EUR.
But you can also unsolder the DIP24 module and use a programmer with ZIF socket. No, better not 5V programmers.

Code: [Select]

int TDS3000_get_battery_flag ()
{
    int battery_flag;
    battery_flag = GetDS1742W (0x7fc) >> 7;
    return battery_flag;
}

void TDS3000_read_RTC (int *array)
{
    int i=0;

    SetDS1742W (0x7f8, 0x40);
    array[i++] = HexByteToDec(GetDS1742W (0x7f9) & 0x7f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fa) & 0x7f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fb) & 0x3f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fc) & 0x07);
    array[i++] = HexByteToDec(GetDS1742W (0x7fd) & 0x3f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fe) & 0x1f);
    array[i++] = HexByteToDec(GetDS1742W (0x7ff) & 0xff);
    array[i++] = HexByteToDec(GetDS1742W (0x7f8) & 0x3f);
    SetDS1742W (0x7f8, 0x00);
}

void TDS3000_show_RTC ()
{
    int array[8];
    TDS3000_read_RTC (array);
    printf ("TDS3000 RTC reads date/time %02d/%02d/%04d %d:%02d.%02d \n", array[4], array[5], 100*array[7] + array[6], array[2], array[1], array[0]);
}

void TDS3000_clear_RTC ()
{
    int i, k=0;
    int v = 0xff;
    printf ("clearing NVRAM in DS1742W/DS1744W chip at 0x%08x\n", base_DS1742);
    printf (" to 0x");
    scanf ("%x", &v);
    for (i=0; i<0x7f8; i++)
    {
        if (v < 0)
        {
            SetDS1742W (i, k);
            k -= v;
        }
        else
            SetDS1742W (i, v);
    }
    printf ("done\n");
}

void fill_buffer_random(unsigned char *buffer, unsigned int len)
{
    unsigned int i;
    srand(time(0));
    for (i=0; i<len; i++)
        *buffer++ = rand() & 0xff;
}

#define test_bytes_size 6
//#define test_bytes_size 256

int check_RTC_DS1742 (unsigned int test_at_address)
{
    int i, r = 1;
    unsigned int backup_address = base_DS1742;
    int array[8];
    int array2[8];

    base_DS1742 = test_at_address;
    TDS3000_read_RTC (array);

    unsigned int random_bytes[test_bytes_size];
    unsigned int backup_array[test_bytes_size];

    srand(time(0));
    for (i=0; i<test_bytes_size; i++)
        random_bytes[i] = rand() & 0xff;

    for (i=0; i<test_bytes_size; i++)
        backup_array[i] = GetDS1742W (i);

    for (i=0; i<test_bytes_size; i++)
         SetDS1742W (i, random_bytes[i]);
/*
    for (i=0; i<test_bytes_size; i++)
    {
        printf ("%02x=%02x ", GetDS1742W (i), random_bytes[i]);
        if ((i & 0x1f) == 0x1f)
            printf ("\n");
    }
*/
    for (i=0; i<test_bytes_size; i++)
        if (GetDS1742W (i) != random_bytes[i])
            r = 0;

    if (r)
    {
        int retry = 0;
        do
        {
            TDS3000_read_RTC (array);
            WaitMilliSeconds (1200); // it must have ticked one second within 1.2 seconds lapsed in PC
            TDS3000_read_RTC (array2);
            if (array[0] != array2[0])
                r |= 2;
            else
            {
                printf ("It did not tick... Trying to start DS174xW RTC clock\n");
                TDS3000_set_time_date (); // attempt to make it go
            }
        } while (retry++ < 2);
    }

    if (r==3)
    {
        if (TDS3000_get_battery_flag ())
            r |= 4;
    }

    for (i=0; i<test_bytes_size; i++)
         SetDS1742W (i, backup_array[i]);

    base_DS1742 = backup_address;

    return r;
}

uint32_t Get_DWORD_DS1742W (uint32_t address)
{
    uint32_t lw = 0;

    uint8_t *p = (uint8_t*)&lw;
    p += 3;
    for (int i=0; i<4; i++)
       *p-- = GetDS1742W (address++);

    return lw;
}

void Set_DWORD_DS1742W (uint32_t address, uint32_t lw)
{
    uint8_t *p = (uint8_t*)&lw;
    p +=3;
    for (int i=0; i<4; i++)
       SetDS1742W (address++, *p--);
}


#define ENGINE_HOURS_IN_NVRAM   0x07E0
#define MAC_ADDRESS_IN_NVRAM    0x06F0

void edit_hours()
{
    int32_t minutes;

    minutes = Get_DWORD_DS1742W (ENGINE_HOURS_IN_NVRAM);

    printf ("engine hours now is %d minutes = %1.2f hours\n", minutes, ((float)minutes)/60.0);
    printf ("enter new value in hours or enter 0 to skip: ");
    scanf ("%d", &minutes);
    if (minutes > 0)
        Set_DWORD_DS1742W (ENGINE_HOURS_IN_NVRAM, 60 * minutes);
}

void copy_MAC_to_NVRAM (uint8_t *six_bytes)
{
    int i;
    uint32_t address = MAC_ADDRESS_IN_NVRAM;

    printf ("old values: ");
    for (i=0; i<6; i++)
        printf ("%02x:", GetDS1742W (address++));
    printf ("\nnew values: ");
    address -= 6;

    for (i=0; i<6; i++)
        SetDS1742W (address++, *six_bytes++);

    address -= 6;
    for (i=0; i<6; i++)
        printf ("%02x:", GetDS1742W (address++));
    printf ("\n");
}



.....
            case '$':
                srand(time(0));

                random_bytes[0] = 0x08;     // Tektronix Inc MAC addresses must start with 080011
                random_bytes[1] = 0x00;
                random_bytes[2] = 0x11;

                for (i=3; i<6; i++)
                    random_bytes[i] = rand() & 0xff;

                for (i=0; i<6; i++)
                {
                    printf ("%02x", random_bytes[i]);
                    if (i<5)
                        printf (":");
                }
                printf("\n");

                F = fopen (TDS3EM_FlashRomFileName, "wt");
                for (i=0; i<6; i++)
                {
                    fprintf (F, "%02x", random_bytes[i]);
                    if (i<5)
                        fprintf (F, ":");
                }
                fprintf (F, "%c", 0);
                i = 12+5+1;
                while (i++ < 32)
                {
                    fprintf (F, "%c", 0xff);
                }
                fclose (F);
                printf ("new file %s is created - but not yet programmed!\n", TDS3EM_FlashRomFileName );

                printf ("copy it to NVRAM? (y/n)");
                ch = getch();
                printf ("%c\n", ch);
                if (ch == 'y')
                {
                    copy_MAC_to_NVRAM (random_bytes);
                }
                break;


....


[lern01]

This C code tells you where to find MAC and 'engine hours' in the DS1742W memory. Engine hours is specified in minutes. MAC is just 6 binary bytes. But they must start with 0x08, 0x00, 0x11 as that's what the firmware checks as allowed "Tektronix Inc" MAC addresses. The next three bytes: best to use a random number generator so that not all devices that we fix get the same MAC address as the one that was published as valid image in the post that you referenced.

To answer the question:

#define ENGINE_HOURS_IN_NVRAM   0x07E0 - 4 bytes uint32_t, minutes not hours
#define MAC_ADDRESS_IN_NVRAM    0x06F0 - 6 bytes
No checksums, crc's  or anything to check data integrity for these fields...

A corrupted / erased DS1742W can be reloaded in situ via the BDM interface (100 pin expansion port plugin) module and PC software for that. I have a few boards left at present. 100 EUR.
But you can also unsolder the DIP24 module and use a programmer with ZIF socket. No, better not 5V programmers.

Code: [Select]

int TDS3000_get_battery_flag ()
{
    int battery_flag;
    battery_flag = GetDS1742W (0x7fc) >> 7;
    return battery_flag;
}

void TDS3000_read_RTC (int *array)
{
    int i=0;

    SetDS1742W (0x7f8, 0x40);
    array[i++] = HexByteToDec(GetDS1742W (0x7f9) & 0x7f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fa) & 0x7f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fb) & 0x3f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fc) & 0x07);
    array[i++] = HexByteToDec(GetDS1742W (0x7fd) & 0x3f);
    array[i++] = HexByteToDec(GetDS1742W (0x7fe) & 0x1f);
    array[i++] = HexByteToDec(GetDS1742W (0x7ff) & 0xff);
    array[i++] = HexByteToDec(GetDS1742W (0x7f8) & 0x3f);
    SetDS1742W (0x7f8, 0x00);
}

void TDS3000_show_RTC ()
{
    int array[8];
    TDS3000_read_RTC (array);
    printf ("TDS3000 RTC reads date/time %02d/%02d/%04d %d:%02d.%02d \n", array[4], array[5], 100*array[7] + array[6], array[2], array[1], array[0]);
}

void TDS3000_clear_RTC ()
{
    int i, k=0;
    int v = 0xff;
    printf ("clearing NVRAM in DS1742W/DS1744W chip at 0x%08x\n", base_DS1742);
    printf (" to 0x");
    scanf ("%x", &v);
    for (i=0; i<0x7f8; i++)
    {
        if (v < 0)
        {
            SetDS1742W (i, k);
            k -= v;
        }
        else
            SetDS1742W (i, v);
    }
    printf ("done\n");
}

void fill_buffer_random(unsigned char *buffer, unsigned int len)
{
    unsigned int i;
    srand(time(0));
    for (i=0; i<len; i++)
        *buffer++ = rand() & 0xff;
}

#define test_bytes_size 6
//#define test_bytes_size 256

int check_RTC_DS1742 (unsigned int test_at_address)
{
    int i, r = 1;
    unsigned int backup_address = base_DS1742;
    int array[8];
    int array2[8];

    base_DS1742 = test_at_address;
    TDS3000_read_RTC (array);

    unsigned int random_bytes[test_bytes_size];
    unsigned int backup_array[test_bytes_size];

    srand(time(0));
    for (i=0; i<test_bytes_size; i++)
        random_bytes[i] = rand() & 0xff;

    for (i=0; i<test_bytes_size; i++)
        backup_array[i] = GetDS1742W (i);

    for (i=0; i<test_bytes_size; i++)
         SetDS1742W (i, random_bytes[i]);
/*
    for (i=0; i<test_bytes_size; i++)
    {
        printf ("%02x=%02x ", GetDS1742W (i), random_bytes[i]);
        if ((i & 0x1f) == 0x1f)
            printf ("\n");
    }
*/
    for (i=0; i<test_bytes_size; i++)
        if (GetDS1742W (i) != random_bytes[i])
            r = 0;

    if (r)
    {
        int retry = 0;
        do
        {
            TDS3000_read_RTC (array);
            WaitMilliSeconds (1200); // it must have ticked one second within 1.2 seconds lapsed in PC
            TDS3000_read_RTC (array2);
            if (array[0] != array2[0])
                r |= 2;
            else
            {
                printf ("It did not tick... Trying to start DS174xW RTC clock\n");
                TDS3000_set_time_date (); // attempt to make it go
            }
        } while (retry++ < 2);
    }

    if (r==3)
    {
        if (TDS3000_get_battery_flag ())
            r |= 4;
    }

    for (i=0; i<test_bytes_size; i++)
         SetDS1742W (i, backup_array[i]);

    base_DS1742 = backup_address;

    return r;
}

uint32_t Get_DWORD_DS1742W (uint32_t address)
{
    uint32_t lw = 0;

    uint8_t *p = (uint8_t*)&lw;
    p += 3;
    for (int i=0; i<4; i++)
       *p-- = GetDS1742W (address++);

    return lw;
}

void Set_DWORD_DS1742W (uint32_t address, uint32_t lw)
{
    uint8_t *p = (uint8_t*)&lw;
    p +=3;
    for (int i=0; i<4; i++)
       SetDS1742W (address++, *p--);
}


#define ENGINE_HOURS_IN_NVRAM   0x07E0
#define MAC_ADDRESS_IN_NVRAM    0x06F0

void edit_hours()
{
    int32_t minutes;

    minutes = Get_DWORD_DS1742W (ENGINE_HOURS_IN_NVRAM);

    printf ("engine hours now is %d minutes = %1.2f hours\n", minutes, ((float)minutes)/60.0);
    printf ("enter new value in hours or enter 0 to skip: ");
    scanf ("%d", &minutes);
    if (minutes > 0)
        Set_DWORD_DS1742W (ENGINE_HOURS_IN_NVRAM, 60 * minutes);
}

void copy_MAC_to_NVRAM (uint8_t *six_bytes)
{
    int i;
    uint32_t address = MAC_ADDRESS_IN_NVRAM;

    printf ("old values: ");
    for (i=0; i<6; i++)
        printf ("%02x:", GetDS1742W (address++));
    printf ("\nnew values: ");
    address -= 6;

    for (i=0; i<6; i++)
        SetDS1742W (address++, *six_bytes++);

    address -= 6;
    for (i=0; i<6; i++)
        printf ("%02x:", GetDS1742W (address++));
    printf ("\n");
}



.....
            case '$':
                srand(time(0));

                random_bytes[0] = 0x08;     // Tektronix Inc MAC addresses must start with 080011
                random_bytes[1] = 0x00;
                random_bytes[2] = 0x11;

                for (i=3; i<6; i++)
                    random_bytes[i] = rand() & 0xff;

                for (i=0; i<6; i++)
                {
                    printf ("%02x", random_bytes[i]);
                    if (i<5)
                        printf (":");
                }
                printf("\n");

                F = fopen (TDS3EM_FlashRomFileName, "wt");
                for (i=0; i<6; i++)
                {
                    fprintf (F, "%02x", random_bytes[i]);
                    if (i<5)
                        fprintf (F, ":");
                }
                fprintf (F, "%c", 0);
                i = 12+5+1;
                while (i++ < 32)
                {
                    fprintf (F, "%c", 0xff);
                }
                fclose (F);
                printf ("new file %s is created - but not yet programmed!\n", TDS3EM_FlashRomFileName );

                printf ("copy it to NVRAM? (y/n)");
                ch = getch();
                printf ("%c\n", ch);
                if (ch == 'y')
                {
                    copy_MAC_to_NVRAM (random_bytes);
                }
                break;


....


Hi, sicco, I am a newbie, how to operate the above C code? I used TL866 to program DS1742W, and an error was reported (see the picture below), and the DS1742W data could not be cleared (stop power supply, and remove the battery). As long as I inserted the TL866 and wrote data, an error was reported saying that the chip data is different from the buffer data.

[sicco]

lern01, I don’t know.
Maybe your DS1742W is dead now because you gave it 5V as VCC. The -W suffix means it’s a 3.3V device…
Maybe it survives that 5V, but does not accept writes when VCC is as high as 5V.
Possibly with a really dead lithium batter inside it does not power the RAM area, despite having VCC of 3 or 5 volts. Cut your way into the DS1742W, from the top, from the pin 12 pin 13 side, find and disconnect the old coin cell inside, and wire a fresh 3V to what used to go to the old battery +. Battery - to GND on pin 12 of the DS1742W,
Maybe it then works again. Maybe not….

The C code that i shared is from the BDM backdoor into the TDS3000. Shared to illustrate what DS1742W memory bytes contain engine hours, mac addrress etc. That code will never run on the sort of programmer that you now use.

[Jarek]

I have a tds3014b, it stops at the start screen.
NVRAM is good.
I thought it was a ROM. I desoldered and read these memories. I am attaching the files, maybe they will be useful to someone.
I programmed new ones using other files from the forum.
Nothing has changed. I'm still looking for the fault.

[sicco]

What does it say on the serial engineering port?
https://groups.io/g/TekScopes/topic/tektronix_tds3034b_boot/104242499?p=,,,20,0,0,0::recentpostdate/sticky,,,20,0,0,104242499,previd%3D1707443608543731339,nextid%3D1707015820604178330&previd=1707443608543731339&nextid=1707015820604178330

[Jarek]

Thank you Sicco for your suggestion.
I read all your posts, you did an amazing job.
I have a TDS3GV card only , I'm ordering the FT4232 controller board and will try to read the serial port.