Tektronix TDS3012B repair help needed

[james_s]

Now this seems to be getting somewhere. I've added one of the expansion connectors to my cart so the next time I order parts I'll get one of those and can try it in my dead one.

[cpuchip]

My connectors just arrived today, I'll have to solder on a few wires and then make my own debug board I can solder this too. Does anyone have a starting KiCad project for an expansion board?

[james_s]

I was just going to solder wires to the connector pins and slip a bit of heatshrink over each. I suppose it could be worthwhile to lay out a board with a USB UART, some buffers for the bus and a prototyping area with a grid of holes or something.

[cpuchip]

I'm putting together something more static that can be used for info on these scopes:
https://github.com/cpuchip/TekTDS30xyz

I've added a few pins on the TE connector and some info on the read me. Not really much, but I plan to add a home brew expansion board with KiCad at some point, unless someone wants to beat me to it.

Let me know if any of you want direct access to that repo for commits. I'll spend the next couple of days flushing out the TE connector pin out from other places on this form, and added what I know about the NVRam. Then I'll probably start in on some KiCad project, but I don't even know what dimensions to make the PCB, what did you use sicco on your home made expansion board?

[m k]

Just found the TDS3012b ROM images shared by YetAnotherTechie, pasted the two 16 bits wide files into one 32 bit file, and then see interesting text in the lower part of the code. Clearly looks like messages for detailed self tests, with pass/fail strings that would end up somewhere. But where is that somewhere, how to read / log / print that??

In case there's a password somewhere I spotted XYZ something around IP iddresses.

[cpuchip]

I'm looking at the BDM doc I found for the MPC8xxx processors

Sicco do you know where the:
SRESET (Pin 65)
HRESET (Pin 66)
DSDI (Pin 63)
DSDO (Pin 62)
FRZ/VFLS0 (Pin 61 as FRZ) (looking at Datasheet H2) is this on TE 100?
FRZ/VFLS1 (Pin 61 as FRZ) (looking at Datasheet J3) is this on TE 100?

pins are? You mentioned that they were on the TE connector

I've not yet tried JTAG missing the TMS pin yet on this board. I finally have a TJAG probe, though I think I'm going to get the FT232H breakout board from adafruit, that seems more straight forward to use.

[cpuchip]

I've updated my TE connector pinout page here: https://github.com/cpuchip/TekTDS30xyz/blob/main/TE%20100%20pinout.md
You'll have to read over it to let me know if I've missed anything or made any mistakes.

Pin 11 is the only one not marked with something. also pmercier was unsure of these pins:
11 ?? No information that I can find
22 (was mixed up with SNI_RCLK & /INT )
25 as possibly *WAIT
26 either *REG or *ALE
27 maybe is A20
74 possibly *OE (note is that Output enable in regards to whatever the TE 100 pin expansion cards wants to put on the Data bus?)
77 *TA

I used this page: https://hackaday.io/project/172242-extension-card-for-tds3000-scopes/log/179520-the-actual-informations
and this thread to help fill in the holes: https://www.eevblog.com/forum/testgear/reverse-engineering-tektronix-tds3gv-module-for-tds3000-series-oscilloscopes/75/

[sicco]

The connector pinout: see the pdf for the schematics that I shared in post just a few days ago in this same topic thread. I made a KiCAD symbol for it.

Yesterday I managed to get an old Abatron BDI2000 BDM/Jtag unit hooked up to in the TDS3034, and with that I could read out the flash ROM on the main board. BDM is not Jtag, but using the same pins mostly, except for TMS that BDM does not use at all. BDM definition of a 10 pin header is also different from what Jtag has defined. But the TDS3000 has neither. It might be that the -b and or -c versions do have the 10 pin debug/program headers, it looked like that on some of the pictures or youtubes that I came across.

[sicco]

This item if you scrol back up:
Re: Tektronix TDS3012B repair help needed
« Reply #40 on: November 23, 2020, 01:17:06 pm »

I noticed that from an iPad clicking on the pdf attachment link does not work, so use a PC to open the schematics.

[cpuchip]

Yesterday I managed to get an old Abatron BDI2000 BDM/Jtag unit hooked up to in the TDS3034, and with that I could read out the flash ROM on the main board. BDM is not Jtag, but using the same pins mostly, except for TMS that BDM does not use at all. BDM definition of a 10 pin header is also different from what Jtag has defined. But the TDS3000 has neither. It might be that the -b and or -c versions do have the 10 pin debug/program headers, it looked like that on some of the pictures or youtubes that I came across.

Wait what! You got BDM working?! that's great news! I definitely don't have an BDI2000... Did you use BDM? and what program did you use to talk to the MPC860?

[sicco]

The program for BDI2000, i got nothing initially after scoring my unit on eBay for 50 Euros. Then searched and searched and searched until i found something in China. Posted that elsewhere in forum for BDI2000 on EEVBlog.

It’s not straightforward, you need both Ethernet and RS232 to initialise the module. The PC from which you run the tool needs to run a FTP server, and a Telnet session, but it is possible. There’s a special config file that sets the MPC860 config registers. Lots of config registers to set... These say for example what address range is used for which of 8 or so /CS pins. Plus how to set /CS, for how long, and so on. I used brute force with the config file from China, which I knew was not for a TDS3000 main board, but something else MPC860 PowerPC running also something VxWorks. Close enough, fingers crossed. It did allow me to work back where the boot roms were mapped, and from there I could read code that strongly resembled the rom code for v3.39 shared earlier in this forum thread. So could not yet run scope code in debug mode, i.e. not able yet to single step or set breakpoints. Not sure I want that either. Without the Tektronix C source code that would be pretty tough anyway.
But maybe the original Tektronix engineers from 20 years back now read these posts, and maybe also they and their employer agree that by now it is time to donate that source code to science. To us. So publish it quietly in a github corner or so. As a tribute to their Brand image, reputation. One can always ask...

On why I go into this deep dive: ongoing mission is to make a super plugin that fixes the TDS3K empty battery DS1744 design flaw, that also offers isolated serial, USB, WiFi, Bluetooth and Ethernet. And now also BDM connector plus that other diagnostics second serial port. For Ethernet I still need an image of the TDS3EM rom code, plus a programmer for the AMD29EV800 rom chip on it. My hope is that someone out here can get me that code, or if not, that i can find this code in the image for the TDS3000-b motherboards that we have already.

[cpuchip]

Okay, I've looked at getting a BDI2000, but there's just non available in my price range (they're over 300$+ here in the states, and there's only like 2 of them available), I did find that OCDemon usbWiggler Macraigor can program the MPC860 processor (I think) and I found some of those on ebay.com for 20$ so I've ordered one.

[cpuchip]

SRESET (Pin 65)
HRESET (Pin 66)
DSDI (Pin 63)
DSDO (Pin 62)
FRZ/VFLS0 (Pin 61 as FRZ) (looking at Datasheet H2) is this on TE 100?
FRZ/VFLS1 (Pin 61 as FRZ) (looking at Datasheet J3) is this on TE 100?

Are those the pins you used for the BDM interface?
I found this as the pin config of the Wiggler to use:

FRZ or VFLS0    o   1   2  o  SRESET
 GND               p   3   4  i   DSCK
 GND               p   5   6  o  FRZ or VFLS1
 RESET\           oc  7   8   i   DSDI
 TVcc               p   9  10 o  DSDO

where:
• o = output from target processor to OCD interface
• i = input to target processor from OCD interface
• p = power pin
• oc = open collector driven from OCD interface, either floating or actively held
low

Can you confirm that you used pin 61 IRQ6 or FRZ as your debug indicator on the BDM adapter?

[sicco]

Yes, those were the pins i used. IRQ6 for FRZ, only one of the two.
Plus DSCK, DSDI, DSDO, SRESET, HRESET, GND (2x) and target VDD.

[sicco]

More progress to report with the BDM using the Abatron BDI2000. See also attached .txt files, one for what I got via the BDI2000 Telnet port, one for the config file that ftp's into the BDI2000 when it boots up, and one from the TDS3000 diagnostics port on pins 13 and 14, a FTDI-TTL cable, Putty at 38400,n,8,1.

The config file is basically totally empty now. Because my TDS3000 has working flash roms, and from there it boots up and gets its proper configuration for the memory map and what is CS0 ... CS7 etc.
All I need to type into the BDI2000 Telnet console is 'reset run', then within a few seconds I must type 'halt' and then 'go'. Without the halt and go, it does not decently boot up, but with these two extra commands it does a full boot and allows me to halt, single step trace, inspect ram, registers, upload code, edit code, download code the whole lot. And I assume that includes erase and reflash as well, but I'm cautious for now.
So that map is:
CS0: boot ron = flash on mainboard. At 0xffc00000..0xffffffff.
CS1: DRAM - but that gets mapped differently. I think it sits at 0x00000000..0x0x007fffff.
CS2: the DS1742W RTC/NVRAM, mapped at 0x02800000..0x028007ff. You can see the seconds ticking, and the time/date in BCD at the top at 0x028007f0..0x028007ff
CS3 - don't know yet - likely i/o to the scope ADCs
CS4 - don't know yet - likely i/o to the scope ADCs
CS5 - don't know yet - likely i/o to the scope ADCs
CS6 - the CE1 signal on the expansion port, pin 78.
CS7 - the CE2 signal on the expansion port, pin 79. That's the one byte module identifier. The high 4 bits indicate what module is plugged in. 0x0*=TDS3VM, serial RS232+VGA, 0x1*=TDS3GM, serial+GPIB, 0x2*=TDS3EM, Ethernet+serial, 0x3*=G01 DIGITAL VIDEO, 0x4*= TDS3GV, higher numbers gets me 'incompatible firmware' - so future expansion i guess.

Now, I remade a TDS3EM on my super plugin with DS1744 RTC, and that now gets recognized as a TDS3EM, and the scope even sees that my flash rom on the module is still blank. So looks like the final step is to get that flash code as a binary or hex file, and then my BDI2000 will be able to flash it! But who is willing to share me taht code? Or lend my an original TDS3EM so that I can read it out. Maybe it's just the MAC address, maybe it's the full Ethernet stack. Any help appreciated.

Just reflashing TDS3000 firmware with the 4 floppy disks (i went back from 3.41 to 3.39) did not do the trick of also flashing the TDS3EM plugin module flash chip.

Bedtime now in Holland.

[sicco]

A bit of a side topic, but might be worth sharing: on the mechanism behind PASSWORD PITBULL and MCONFIG TDS3054: what that does is append a string in the TDS3000 main board rom image. The exact address position seems to depend on FW version, and model like -b or -nothing, but it looks like the mechanism is there also for firmware 3.41. So I guess it is the same approach for the -c versions. The 3.41 firmware and the -c models don't do the PITBULL MCONFIG anymore, so for now we were stuck with the older models. But this here may be a clue on how to crack that puzzle for -c etc.

If you make a dump of the binary files (like those two for u610_339 and U620_339 shared before by others in this forum), and then search for ascii string "TDS 30" (no quotes, but with the space), then you find two relevant parts. The first one I think is the original firmware when a unit left the Tektronix factory. But then higher up in the rom code, there's a section where additional strings can get appended. The MCONFIG TDS30nn secret command simply appends the null terminated string TDS 30nn to that list - provided it is a known model number, fits the number of channels etc. The list grows and grows every time you do a MCONFIG, overwriting already erased (0xff) data. So no need to erase rom flash sectors upfront. Looks like you can do it 100+ times should you wish so.

At the next reboot, it reads that list of strings, picks the last one from that list, and that will be how it will configure itself. That configuration act involves a lot of internal data partition reshuffling in the roms it seems, but that's ok.

Here's a snippet for what the version upgrade attempts status is in the image for u610_339 and U620_339 that was shared earlier:
2c07a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2c07c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2c07e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2c0800: ffffffff 54445320 33303334 42000000 00780000 00f40000 01ea0000 03c40000 ....TDS 3034B....x..............
2c0820: 07890000 00780000 00f30000 01e90000 03c20000 07840000 00770000 00f10000 .....x...................w......
2c0840: 01e60000 03bb0000 07780000 00790000 00f50000 01ed0000 03c90000 07940000 .........x...y..................
2c0860: 00760000 00f00000 01e40000 03b60000 076e0000 00790000 00f50000 01ed0000 .v...............n...y..........


and then much further down:

2d8200: 00000000 00000000 0000bee6 3333be64 00004074 70b83ef6 57000000 0000bf00 ............33.d..@tp.>.W.......
2d8220: 1b33bf00 1b33bf00 1b33be60 b1f83e3a 13333e3a 13333e3a 13333f00 0000bf19 .3...3...3.`..>:.3>:.3>:.3?.....
2d8240: 34cdbf19 34cdbf19 34cdbf00 00003e7b 53babeea 3fa33f23 e6683e9a 00000000 4...4...4.....>{S...?.?#.h>.....
2d8260: 00000000 00000000 01000000 03800005 00000000 00000536 111e0a00 07d20000 .......................6........
2d8280: ff005444 53203330 35344200 54445320 33303634 4200ffff ffffffff ffffffff ..TDS 3054B.TDS 3064B...........
2d82a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d82c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d82e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d8300: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d8320: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d8340: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d8360: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................
2d8380: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ................................


Which makes me conclude that the owner here originally had a TDS3034B, which he managed to upgrade to a TDS3054B, and then, after that, he upgraded to TDS3064B.

My gut feeling now is that in a TDS3000-c unit, the act of appending "TDS 3064C" to the bottom of the list of null-terminated ansi-C ascii strings would result in the same bandwidth upgrade for, say, a TDS3012C.

Some more evidence supporting that below - in picture attached. That's from my TDS3034-nothing, where I went back and forth multiple times.
Also attached my updated Abatron BDI2000 BDM config file for the TDS3000 PowerPC XPC860.

Disclaimer: I have not yet written anything into my rom's, only observed what happens (what the delta is inside the flash roms) when doing the BW hack in FW 3.39 in my old TDS3034. But it looks promising for -c models I think.

[james_s]

This makes me wonder if a corrupted string being written to that location could cause the boot failures like we've seen. I wonder what happens if you do manage to fill the space? Maybe it's smart enough to stop writing at some point, or start over at the beginning? The bandwidth upgrade remains after doing a firmware update so maybe it masks off that space and doesn't mess with it.

[sicco]

Today I had the courage to finally do the erase command, followed by a prog command. If that would not work flawlessly, then I would have lost my TDS3034. So I was a bit worried. But I was lucky, so it survived after reflashing with the Abatron BDI2000 BDM tool. First upload the rom image, then do a verify command, and only if that works, only then I knwe that the settings for chip type, size, file format, offsets etc was probably good enough to dive into the deep.

Tried a couple of different firmware's with several manual edits. It worked as expected more or less. With FW 3.41, I can change from TDS30x4 with x at 1, 2, 3 or 5. But that only works if I edit the first entry where there was a list of entries before. Padding the list of strings as seemed to happen with MCONFIG in FW 3.39 did not do the trick in FW 3.41. Only overwriting the first list entry works. If it doesn't work, then typically the scope defaults to the lowest setting, so to TDS3014 in my case. It also does that if I try to run with a TDS3012B image.

Surprised to see that there is no ROM checksum check over this part of the main board flash roms. the VxWorks bootrom reports two checksums, one for Boot flash, another for Code Flash, and both always passed, irrespective of the small edits I made in the full rom images.

Updated Abatron BDI2000 config file attached, plus a telnet session log from the BDI2000.

[cpuchip]

Today I had the courage to finally do the erase command, followed by a prog command.

You Sicco are a brave soul! and congrats on not messing up your scope.

I just received my BDM probe, I hope it has enough features to get me along in this debug process. I hope to have a connector wired up with it, and the two serial ports this week, but we'll see, I'm also searching for a job now so my time in the evenings are limited.