Possible ticking time bomb in Tek DPO3000 and MSO3000 series of scopes DPO4000 ?

[Jwalling]

This may be a ticking time bomb in Tek DPO3000 and MSO3000 series of scopes. It also may affect the DPO4000 and MSO4000 scopes as, IIRC, they use a similar NVRAM scheme. It's not a Dallas chip you can remove, read-out, and program a fresh one, but a soldered in battery on the acquisition  board. This scope came to me on a repair job with a battery that was very dead. This is the first time I've seen a dead battery on one of these, so I can't be sure of this fault.

I opened a ticket with Tek:

Hello,
I have a DPO3054 serial # C010454 that does not work with Ethernet. Looking into the netork settings, I can see that it does not have a MAC address - the field is blank. Both LEDs on the Ethernet connector do light when the cable is plugged in. Everything else on the rear of the scope (VGA, USB, etc) are working.
This scope had a dead battery on the acquisition board that was just replaced. I do not know whether this is the root cause of the failure, or if this problem existed before the battery died. Is there any way to recover the MAC address?

Response:

Hi Jay,

 

Unfortunately, I can’t help you past updating the firmware and resetting the DHCP. After doing some research, it looks like the absence of the MAC address is most likely due to a hardware failure. You will need to send your scope in for service to get the issue fixed. The DPO3000 is under Best Effort Repair, meaning that our repair capabilities are limited.

 

Regards,

Casey Lockridge
   

Applications Engineer
   

tek.com

I DON'T think this a hardware failure, if the battery is at fault.

[Jwalling]

Just emailed Casey this:

OK, thanks for the Response Casey.

I have a number of these in the field that I support. Can you definitively confirm with an Engineer who is familiar with the inner workings of the scope, whether the death of the battery will cause the scope to lose it's MAC address. I also support some DPO/MSO4000 series, and would be very grateful if you could find out about these as well.

Thanks again,

Jay

[CJay]

Looks like there may be a MAC related command in the TV84 post with attached txt file

https://www.eevblog.com/forum/testgear/dpo3000-hacks/25/

You probably need to find the serial debug port on the 'scope

[Jwalling]

Looks like there may be a MAC related command in the TV84 post with attached txt file

https://www.eevblog.com/forum/testgear/dpo3000-hacks/25/

You probably need to find the serial debug port on the 'scope

Which I've heard talked about, but have yet to see anyone post about where it is located or pinout.
Thanks.

[Jwalling]

Or maybe USB port...

[Jwalling]

Just emailed Casey this:

OK, thanks for the Response Casey.

I have a number of these in the field that I support. Can you definitively confirm with an Engineer who is familiar with the inner workings of the scope, whether the death of the battery will cause the scope to lose it's MAC address. I also support some DPO/MSO4000 series, and would be very grateful if you could find out about these as well.

Thanks again,

Jay

Not much of an update, but what the hell...

Response from 1-4-2020

Hi Jay,

 

It’s definitely possible that the death of the battery could have caused the MAC address loss. A battery dying can cause the scope to lose system time which will mess with the other internal systems. I don’t know if you are planning on sending the scope in for repair, but our service team would be better at finding the cause of the issue.

"definitely possible" WTF does that mean?

So my next email:

Hi Casey,

The battery has been replaced and the time has been set correctly.

Are you saying that:

1. The MAC address is stored in non-volatile memory, that is powered by the battery when the power is off?

2. If yes, do the MSO/DSO4000 scopes store the MAC address the same way?

Thanks again for your help!

Jay

So far [crickets]

Using it's USB connection, I tried to brute force the MAC address using the first three octets that are assigned to Tektronix. I don't know whether it expects spaces, colons, or nothing, so I tried all three.

Code: [Select]

:MFG:MAC 08 00 11 79 22 91
:MFG:MAC 08:00:11:79:22:91
:MFG:MAC 080011792291

:PASSWord INTEKRITY (only)
:MFG:MAC 08 00 11 79 22 91
:MFG:MAC 080011792291
:MFG:MAC 08:00:11:79:22:91

:MFG:MODe (and using :PASSWord INTEKRITY)
:MFG:MAC 08:00:11:79:22:91
:MFG:MAC 08 00 11 79 22 91
:MFG:MAC 080011792291

:MFG:MODe (NOT using :PASSWord INTEKRITY)
:MFG:MAC 08:00:11:79:22:91
:MFG:MAC 08 00 11 79 22 91
:MFG:MAC 080011792291
None of those worked.

I also looked at some other scopes on my Asus router to see what other first three octets they use:
TDS3034B B041068 CODEX CORP 08:00:3E:01:02:03

That's odd - Codex.

TDS3014C C014072 TEKTRONIX INC 08:00:11:1E:C1:DD

What is strange (though not related to this thread) a TDS3054B with serial prefix B014XXX did not show up on my Asus router, but was working fine on Ethernet in any case. I tried a TDS3012B with serial prefix B027XXX and it behaved the same way.

Anyway, a few pics using a USB connection. The first, an MSO4K that's working correctly.

[Jwalling]

On 1/14/2020 I got this reply:

Hi Jay,

 My apologies for not answering your email sooner. Unfortunately, I haven’t been able to find out where the MAC address is stored. It is likely that the address is stored on the acquisition board, but it would be in NV Flash memory that most likely does not need battery backing.

Regards,

Casey Lockridge

So it's gone from

It’s definitely possible that the death of the battery could have caused the MAC address loss.

To that.

*sigh*

[KE5FX]

What's the actual Ethernet hardware implementation?  Maybe there's a power or communication issue that keeps the Ethernet MAC hardware from talking to the CPU.  They may have just bought an Ethernet-to-SPI or whatever bridge from the "Codex Corp." OEM.  If that's where the MAC address is stored, you might just need to troubleshoot that area of the hardware. 

The battery business may be a red herring, in other words.

[JohnPi]

I (and others) have asked before on this forum where the serial debug port is on these 'scopes. Does anyone have any information please ?

[Jwalling]

What's the actual Ethernet hardware implementation?  Maybe there's a power or communication issue that keeps the Ethernet MAC hardware from talking to the CPU.  They may have just bought an Ethernet-to-SPI or whatever bridge from the "Codex Corp." OEM.  If that's where the MAC address is stored, you might just need to troubleshoot that area of the hardware. 

The battery business may be a red herring, in other words.

Scope is gone, as the customer didn't care about the problem. So I guess I'll wait and see if this problem pops up again with someone else when their battery dies...

The TDS3000 B and C scopes store the MAC address in the Dallas chip, so there would be precedent for this.

[m k]

It seems that that Tek tech didn't tell you all.
Maybe that is the situation where the device must call home using alternative channel.

Is it probable that there are a special console port?
Perhaps commands are rerouted like you wondered.
HTML something was a fashion one day.

I (and others) have asked before on this forum where the serial debug port is on these 'scopes. Does anyone have any information please ?

Where are all pcb pictures?

[tixdave]

I (and others) have asked before on this forum where the serial debug port is on these 'scopes. Does anyone have any information please ?

I have been trying to find the serial debug port on a DPO4034B and I have at last found it!!!
On the back I/O module there is a RS-232 IC chip (U801, ICL3221) right next to the VGA port.
I have pinned it out and it looks like Rx is pin 11 and Tx is pin 4 on the 15 pin VGA connector (unused VGA pins).
Connected it up to putty and had to change the baud from 9600 to 115200 and what do you know, words start showing up in the terminal!!

Hope this helps!

[Jwalling]

I (and others) have asked before on this forum where the serial debug port is on these 'scopes. Does anyone have any information please ?

I have been trying to find the serial debug port on a DPO4034B and I have at last found it!!!
On the back I/O module there is a RS-232 IC chip (U801, ICL3221) right next to the VGA port.
I have pinned it out and it looks like Rx is pin 11 and Tx is pin 4 on the 15 pin VGA connector (unused VGA pins).
Connected it up to putty and had to change the baud from 9600 to 115200 and what do you know, words start showing up in the terminal!!

Hope this helps!

Thanks for that.
This also appears to be the case with the non-suffix MSO/DPO 4000 scopes. However, I get nothing but garbage. I tried baud rates from 9600 up to 230K.

[Jwalling]

Thanks for that.
This also appears to be the case with the non-suffix MSO/DPO 4000 scopes. However, I get nothing but garbage. I tried baud rates from 9600 up to 230K.

Operator error. I was using the wrong type of serial converter at the PC end.

Here's the output of a working MSO4104. Invoking the full tests from the utility menu produces no output, but SPC does. Serial port was set to 9600,n,8,1

Code: [Select]

U-Boot 1.1.4 (Jan  8 2007 - 11:12:14) Tektronix, Inc. V1.06

CPU:   AMCC PowerPC 440EP Rev. C at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled, PCI async ext clock used
       32 kB I-Cache 32 kB D-Cache
Board: Tektronix Route66 IBM 440EP Main Board
VCO: 666 MHz
CPU: 333 MHz
PLB: 133 MHz
OPB: 66 MHz
EPB: 66 MHz
I2C:   ready
DRAM:  128 MB
FLASH: 64.5 MB
PCI:   Bus Dev VenId DevId Class Int
        00  13  10b5  9056  0680  18
        00  15  1002  4c59  0300  17
DISP:  Type 1
In:    serial
Out:   serial
Err:   serial
Enter password - autobooting in 3 seconds
## Booting image at f0000000 ...
   Image Name:   Linux-2.4.20_mvl31-440ep_eval
   Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
   Data Size:    1441010 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Contents:
   Image 0:  1033953 Bytes = 1009.7 kB
   Image 1:   407042 Bytes = 397.5 kB
   Verifying Checksum ... OK
   Uncompressing Multi-File Image ... OK
cmdline is console=ttyS0,9600 quiet bigphysarea=519 panic=2 root=/dev/mtdblock7
rw mem=131072k
   Loading Ramdisk to 07f2b000, end 07f8e602 ... OK
Checking for firmware update...
No USB mass storage devices found to update from.
Linux 2.4.20_mvl31-440ep_eval V 1.15 Tektronix Route66 Tue Jun 22 15:19:50 PDT 2
010
stat of /var/log/dmesg failed: No such file or directory
Warning: loading NiDKEng-1.6 will taint the kernel: non-GPL license - Proprietar
y
  See [url]http://www.tux.org/lkml/#export-tainted[/url] for information about tainted modu
les
Warning: loading NiDUsb-1.6 will taint the kernel: non-GPL license - Proprietary
  See [url]http://www.tux.org/lkml/#export-tainted[/url] for information about tainted modu
les
Warning: loading tek will taint the kernel: non-GPL license - Proprietary
  See [url]http://www.tux.org/lkml/#export-tainted[/url] for information about tainted moSc
ope application starting (normal mode)
---------------------- startScopeApp() running Init code ----------------------
versionBuildFWVersionString(): TimestampString: 25-Apr-12  11:13   
                               VersionFIRMWAREVERSIONversion: v2.68
                               Major ver num: 2 Minor ver num: 68
     Initializing Mia[0]
     Initializing Tek0005[0]
     Initializing Ibm440[0]
     Initializing HFD204ADC[1]
     Initializing HFD204ADC[0]

Model id: 0x03

     Initializing Ltc1658Dac[0]

Board id: 0x01

     Initializing M859[3]
     Initializing M859[2]
     Initializing M859[1]
     Initializing M859[0]
     Initializing Ltc1660Dac[1]
     Initializing Ltc1660Dac[0]
      HFD144[0] ID_REG = 0x00001440
      HFD144[1] ID_REG = 0x00001440
      HFD144[2] ID_REG = 0x00001440
      HFD144[3] ID_REG = 0x00001440
     Initializing Hfd144[0]
     Initializing Hfd144[1]
     Initializing Hfd144[2]
     Initializing Hfd144[3]
Open Max5362 successful.
     Initializing Max5362[0]
     Initializing Ltc1661Dac[1]
     Initializing Ltc1661Dac[0]
 Init ADT7468 and locking.
 Factory Checksum: Stored: 7072, Calculated: 7072  - OK
 Spc CheckSum: stored: 49755 calculated: 49755  - OK
Demux initialization

    Dram calibration
    Dram calibration complete

Dram Calibration results:
-------------------------
DramCal has PASSED on all Demuxs

Demux initialization complete
Starting POST diags

Finished POST diags
---------------------- startScopeApp() running Start code ---------------------
---------------------- startScopeApp() running Run code -----------------------
SIOCSIFFLAGS: Link has been severed
OK to connect by: telnet MSO4104-04TRCT 1072
 SocketServerService: Socket server daemon started on port 4000.
    Protocol: Raw
-----------------------------------------------------------------
startScopeApp() complete; duration = 34.739902 seconds
=================================================================
PID to Task info written to /tmp/threads.txt
  Power Up Completed at 05:11:11
Enter 'ctrl-\' to quit scopeApp

BEGIN SPC, PASSING:


05:24:17 SPC: starting 5:24:17
05:24:17 Signal test
05:24:18  - PASSED
05:24:18 Signal test 0:0:1
05:24:18 Time Interpolator Cal
05:24:24  - PASSED
05:24:24 Time Interpolator Cal 0:0:6
05:24:24 ADC Linearity
05:25:35  - PASSED
05:25:35 ADC Linearity 0:1:11
05:25:35 ADC Offset and Gain
05:25:56  - PASSED
05:25:56 ADC Offset and Gain 0:0:21
05:25:56 ADC Interleave
05:26:21  - PASSED
05:26:21 ADC Interleave 0:0:25
05:26:21 Offset
05:27:20  - PASSED
05:27:20 Offset 0:0:59
05:27:20 BW Offset
05:27:22  - PASSED
05:27:22 BW Offset 0:0:2
05:27:22 DC Balance
05:29:09  - PASSED
05:29:09 DC Balance 0:1:47
05:29:09 Attenuation
05:30:10  - PASSED
05:30:10 Attenuation 0:1:1
05:30:10 VariGain/GainStepsCal
05:33:26  - PASSED
05:33:26 VariGain/GainStepsCal 0:3:16
05:33:26 Trigger Level Gain and Hysteresis 1Meg
05:33:38  - PASSED
05:33:38 Trigger Level Gain and Hysteresis 1Meg 0:0:12
05:33:38 Trigger Level Gain and Hysteresis 50 Ohm
05:33:50  - PASSED
05:33:50 Trigger Level Gain and Hysteresis 50 Ohm 0:0:12
05:33:50 Trigger Level Offset 1Meg
05:33:59  - PASSED
05:33:59 Trigger Level Offset 1Meg 0:0:9
05:33:59 Trigger Level Offset 50 Ohm
05:34:07  - PASSED
05:34:07 Trigger Level Offset 50 Ohm 0:0:8
05:34:07 Digital Trigger Level
05:34:14  - PASSED
05:34:14 Digital Trigger Level 0:0:7
05:34:14 Adg523 Word Recognizer Delay
05:36:26  - PASSED
05:36:26 Adg523 Word Recognizer Delay 0:2:12
05:36:26 Adg523 Analog Delay
05:39:23  - PASSED
05:39:23 Adg523 Analog Delay 0:2:57
05:39:23 Adg523 Extra Delay Paths
05:39:23  - PASSED
05:39:23 Adg523 Extra Delay Paths 0:0:0
05:39:23 Digital Hsr Deskew
05:40:41  - PASSED
05:40:41 Digital Hsr Deskew 0:1:18
05:40:41 SPC Total Time: 0:16:24
05:40:41 Writing SPC Consts:
  SPC Version: 11
  Date (mon:day:year): 4:1:2021
  Time (hr:min:sec): 5:40:41
05:40:41  FactoryDate: (mon:day:year) 7:19:2008
 Factory Time: (hr:min:sec) 22:25:7



[EE-digger]

Some Tek scopes (TDS7xx comes to mind) only stored user settings in their Dallas chip.  As Jay mentioned, others stored more than that.

One place I worked in the past used Dallas chips in their very expensive high speed BER/transmission test equipment.  Critical calibration constants for line conditioning and timings were stored in those chips.  Dumb design which renders those units to a high position in the recycling pile.

[analogRF]

Thanks for that.
This also appears to be the case with the non-suffix MSO/DPO 4000 scopes. However, I get nothing but garbage. I tried baud rates from 9600 up to 230K.

Operator error. I was using the wrong type of serial converter at the PC end.

Here's the output of a working MSO4104. Invoking the full tests from the utility menu produces no output, but SPC does. Serial port was set to 9600,n,8,1

Code: [Select]

U-Boot 1.1.4 (Jan  8 2007 - 11:12:14) Tektronix, Inc. V1.06

CPU:   AMCC PowerPC 440EP Rev. C at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
       I2C boot EEPROM enabled
       Internal PCI arbiter enabled, PCI async ext clock used
       32 kB I-Cache 32 kB D-Cache
Board: Tektronix Route66 IBM 440EP Main Board
VCO: 666 MHz
CPU: 333 MHz
PLB: 133 MHz
OPB: 66 MHz
EPB: 66 MHz
I2C:   ready
DRAM:  128 MB
FLASH: 64.5 MB
PCI:   Bus Dev VenId DevId Class Int
        00  13  10b5  9056  0680  18
        00  15  1002  4c59  0300  17
DISP:  Type 1
In:    serial
Out:   serial
Err:   serial
Enter password - autobooting in 3 seconds
## Booting image at f0000000 ...
   Image Name:   Linux-2.4.20_mvl31-440ep_eval
   Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
   Data Size:    1441010 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Contents:



But can you stop the boot?

I am having trouble stopping the UBoot...needs a password!! 

[analogRF]

I (and others) have asked before on this forum where the serial debug port is on these 'scopes. Does anyone have any information please ?

I have been trying to find the serial debug port on a DPO4034B and I have at last found it!!!
On the back I/O module there is a RS-232 IC chip (U801, ICL3221) right next to the VGA port.
I have pinned it out and it looks like Rx is pin 11 and Tx is pin 4 on the 15 pin VGA connector (unused VGA pins).
Connected it up to putty and had to change the baud from 9600 to 115200 and what do you know, words start showing up in the terminal!!

Hope this helps!

have you been able to stop the UBoot?
what is the password it needs for stopping?

[Jwalling]

But can you stop the boot?

I am having trouble stopping the UBoot...needs a password!! 

Never tried, and I no longer have it.

[tixdave]

have you been able to stop the UBoot?
what is the password it needs for stopping?

I have not been able to, I do not know the password.
Why do you want to stop the UBoot?