Tektronix MSO4000B Front Panel Repair

[crhastre]

Hi all, I have an MSO4104B-L oscilloscope that's having an issue with the front panel and I'm looking for some ideas.  The symptoms are that the scope boots up immediately when plugged in instead of waiting for the power button to be pushed, and once it boots it doesn't respond to any front panel commands.  I started by extracting the boot log from the scope and it's showing an I/O error communicating to the front panel via the I2C bus.

Code: [Select]

U-Boot 2009.08 (Mar 03 2011 - 17:01:14) Tektronix, Inc. V1.01

CPU:   AMCC PowerPC 460EX Rev. B at 600 MHz (PLB=200, OPB=100, EBC=50 MHz)
       No Security/Kasumi support
       Bootstrap Option F - Boot ROM Location I2C (Addr 0x54)
       Internal PCI arbiter disabled
       32 kB I-Cache 32 kB D-Cache
Board: Tektronix Route66B AMCC 460EX Main Board PVR 130218a4
VCO: 1200 MHz
CPU: 600 MHz
PLB: 200 MHz
OPB: 100 MHz
EBC: 50 MHz
Programming SDIA...done
I2C:   ready
DRAM:  Auto calibration -\ \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/                  512 MB
FLASH: 128 MB
PCI:   Bus Dev VenId DevId Class Int
        00  0d  1172  0004  ff00  18
In:    serial
Out:   serial
Err:   serial
Board version: 1 (Proto) 4 channel MSO
I/O board version: 3
SDIA version: 0133
Calibrating VCO...done
Net:   ppc_4xx_eth0
Enter password - autobooting in 3 seconds
## Booting kernel from FIT Image at f8040000 ...
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading init Ramdisk from FIT Image at f8040000 ...
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Flattened Device Tree from FIT Image at f8040000
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0xf824a230
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 1f130000, end 1f1ff5e6 ... OK
   Loading Device Tree to 00ffa000, end 00fff0d0 ... OK
Checking for firmware update...
No USB mass storage devices found to update from.
Linux 2.6.31.4 V 1.11 Tektronix BK Mon Feb 13 10:06:16 PST 2012
Scope application starting (normal mode)
---------------------- startScopeApp() running Init code ----------------------
versionBuildFWVersionString(): TimestampString: 15-Nov-12  14:28   
                               VersionFIRMWAREVERSIONversion: v2.90
                               Major ver num: 2 Minor ver num: 90
     Initializing Sdia[0]

Main Board HW Rev: 0x09

     Initializing Tek0005[0]
     Initializing Ibm460[0]
 feReprogramFeProc: Platform Route66b fw 1028 filefw 1028
 Front Panel Firmware update not needed
   Current firmware 1028 >= 1028
     Initializing HFD204ADC[1]
     Initializing HFD204ADC[0]

Main Board HW ID: 0x02

AFE Board SW ID: 0x02

Main Board SW ID: 0x05

     Initializing Ad5668Dac[1]
     Initializing Ad5668Dac[0]
     Initializing Adt7476[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]
     Initializing Afe[0]
     Initializing MDO[0]
     Initializing Adf4350[0]
     Initializing Tek026[4]
     Initializing Tek026[3]
     Initializing Tek026[2]
     Initializing Tek026[1]
     Initializing Tek026[0]
     Initializing Dac5571[0]
     Initializing Tmp421[4]
     Initializing Tmp421[3]
     Initializing Tmp421[2]
     Initializing Tmp421[1]
     Initializing Tmp421[0]
    Init ADT7476.
 ialInit(): AFE id 0x2, rev 0x4, bI 1
 4104B-L with bI 10
 Factory Checksum: Stored: 39002, Calculated: 39002   - OK
 Spc CheckSum: stored: 31340 calculated: 31340   - 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
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
ERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.
 firmware version read: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
ERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.
 platform version read: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
ERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 2 bytes - got -1 bytes.
 common code version read: Remote I/O error
Installing 44 in front panel.

fpReprogramFrontPanelCpuPrivate(/usr/local/perm/route66_fp.s19)
  fpSRecCheckSum returning 0
  fpSRecRaw: FP_UPDATE_CODE_START_CMD write failed - -1 bytes of 3 written
 Reprogram start: Remote I/O error
Fp software update function reports failure.
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
 1st purge loop: Remote I/O error
ERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.
 firmware version read: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
 2nd purge loop: Remote I/O error
ERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.
 platform version read: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
 3rd purge loop: Remote I/O error
ERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 2 bytes - got -1 bytes.
 common code version read: Remote I/O error
After Fp software update version is -1, expected 44.
  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
  bytes 3 - 0x6 0x0 0x1
 bytes in queue 0
---------------------- startScopeApp() running Start code ---------------------
---------------------- startScopeApp() running Run code -----------------------
  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
  bytes 3 - 0x6 0x0 0x2
 bytes in queue 1
  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
  bytes 3 - 0x6 0x1 0x2
 bytes in queue 0
-----------------------------------------------------------------
startScopeApp() complete; duration = 24.305649 seconds
=================================================================
PID to Task info written to /tmp/threads.txt
  Power Up Completed at 00:15:36
Enter 'ctrl-\' to quit scopeApp

00:15:36  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:36  bytes 2 - 0x2f 0x1
 bytes in queue 0
00:15:36 SocketServerService: Socket server daemon started on port 4000.
    Protocol: Raw
00:15:36  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:36  bytes 2 - 0x2e 0x4b
 bytes in queue 0
00:15:37  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:37  bytes 3 - 0x6 0x0 0x2
 bytes in queue 0
Failed to kill daemon: No such file or directory
00:15:37.381.889 usbtmc488_enable_interface: USBTMC enabled; response buffer size = 261648
Failed to kill daemon: No such file or directory
00:15:37 SDIA version 0x133, non-Trinity, skip calSdiaRunClkSync()
00:15:41 Run Sync Cal - PASSED
00:15:41
  +++++++++++++++++++++++++++++++++++++++++++
  + adc Interleave cal - Powerup
  +++++++++++++++++++++++++++++++++++++++++++
00:15:41 cfg 4, chMask 0x9
00:15:41 srcChId 0, adcMask 0x30, numPipes 2:
00:15:41 Loop 0, MeasuredFreq = 9.522944e+06
00:15:42 Loop 1, MeasuredFreq = 9.523233e+06
00:15:42 Loop 0, MeasuredFreq = 1.333326e+08
00:15:42  ++++ srcCh 1 adcMask 0x30 Interleave Results ++++
00:15:42  +    Final Phase Err:
00:15:42  +     Adc_4 phaseErr: actual -4.79e+00ps, exp < +/- 2.00e+01ps
00:15:42  +         totalPhaseAdjust[adc_4] = -1.085336e+03 ps
00:15:42  +     Adc_5 phaseErr: actual 4.91e+00ps, exp < +/- 2.00e+01ps
00:15:42  +         totalPhaseAdjust[adc_5] = 1.113485e+03 ps
00:15:42  +++++++++++++++++++++++++++++++++++++++++++++
00:15:42 cfg 5, chMask 0x9
00:15:42 srcChId 3, adcMask 0xC0, numPipes 2:
00:15:43 Loop 0, MeasuredFreq = 9.523178e+06
00:15:43 Loop 1, MeasuredFreq = 9.524544e+06
00:15:43 Loop 0, MeasuredFreq = 1.333321e+08
00:15:43  ++++ srcCh 4 adcMask 0xC0 Interleave Results ++++
00:15:43  +    Final Phase Err:
00:15:43  +     Adc_6 phaseErr: actual 7.26e-01ps, exp < +/- 2.00e+01ps
00:15:43  +         totalPhaseAdjust[adc_6] = 4.981936e+02 ps
00:15:43  +     Adc_7 phaseErr: actual -7.39e-01ps, exp < +/- 2.00e+01ps
00:15:43  +         totalPhaseAdjust[adc_7] = -5.077606e+02 ps
00:15:43  +++++++++++++++++++++++++++++++++++++++++++++
00:15:43 Power On Interleave Cal - PASSED
00:15:43 ********************
00:15:43 *  Power up Deskew *
00:15:43 ********************
00:15:43 calPowerUpDeskew: sampleInterval = 4.000000e-10, sampleRate = 2.500000e+09
00:15:43 midCrossTweak = 0.00
00:15:47 tgDacLvl = 2310.2
00:15:49   adc4 skew -2.976953e-08 currentPhase -1.313717e+01 phaseFrac 8.628321e-01
00:15:49   adc5 skew -2.997363e-08 currentPhase -8.150372e+00 phaseFrac 8.496277e-01
00:15:49   adc6 skew -3.054785e-08 currentPhase -1.112415e+01 phaseFrac 8.758533e-01
00:15:49   adc7 skew -3.075996e-08 currentPhase -1.416930e+01 phaseFrac 8.306987e-01
00:15:52 avgMidCross[ch_0] = 5.000821e+03, skew = 3.285156e-10s, adcMask = 0x10
00:15:52   ChIdx_0 skew 3.285156e-10 refSkew -7.148437e-11 phaseBump 1.000000
00:15:52 avgMidCross[ch_1] = 5.000842e+03, skew = 3.369141e-10s, adcMask = 0x20
00:15:52   ChIdx_1 skew 3.369141e-10 refSkew -7.148437e-11 phaseBump 1.000000
00:15:52 avgMidCross[ch_2] = 5.000841e+03, skew = 3.365234e-10s, adcMask = 0x40
00:15:52   ChIdx_2 skew 3.365234e-10 refSkew -7.148437e-11 phaseBump 1.000000
00:15:52 avgMidCross[ch_3] = 5.000825e+03, skew = 3.300781e-10s, adcMask = 0x80
00:15:52   ChIdx_3 skew 3.300781e-10 refSkew -7.148437e-11 phaseBump 1.000000
00:15:52 Power Up Deskew Cal - PASSED
00:15:52 Power Up DeskewRf Cal - PASSED
00:15:52 calSetPowerupAdcPhaseValues chMask = 0xF
00:15:52 Mss Trigger Cal
00:15:52 Mss Trigger Cal - PASSED
00:15:52 Last Cal'd facVersion: 5, current facVersion 5
00:15:52 Last Cal'd SpcVersion: 3, current SpcVersion 3
00:15:53  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:53  bytes 2 - 0x2e 0x4b
 bytes in queue 3
00:15:53  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:53  bytes 2 - 0x2b 0x2
 bytes in queue 2
00:15:53  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:53  bytes 2 - 0x2a 0x2
 bytes in queue 1
00:15:54  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:54  bytes 2 - 0x2e 0x4b
 bytes in queue 0
00:15:54  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:54  bytes 3 - 0x6 0x0 0x1
 bytes in queue 1
00:15:54  fpSendCmd: queued I2C write error on second attemp -1
 fpSendCmd queue: Remote I/O error
00:15:54  bytes 3 - 0x6 0x0 0x2
 bytes in queue 0


If I unplug the J301 connector that connects the front panel assembly to the mainboard the scope boots more quickly but still shows the I2C errors in the boot log.  In this state (with the front panel unplugged) the scope responds to SCPI commands via USB and appears to work correctly otherwise.

Probing around U306 on the circuit board which is a PCA9515A acting as an I2C level shifter from 3.3 to 5V I found that the bus is latching up with both SCL and SDA held low starting at the "1st purge loop" error in the log.  Based on insight from https://www.eevblog.com/forum/repair/tektronix-dpo4034b-stucked-at-tektronix-splash-screen/ I tried replacing this part but that didn't fix the problem.

I substituted in a different bidirectional I2C coupler that gave me some additional insight into the direction of bus traffic and found that the message being sent at the time of failure is this: Master addresses 1110110 with a read (1) flag.  This is acknowledged with (0) by the front panel.  The front panel then responds with 11111111 and sends and ack (0).  At this point the Front Panel is holding both SDA and SCL low and doesn't release them until power cycle.  I've verified this by disconnecting both lines and seeing that the master side goes high on each and the front panel side is still held low.

Has anyone else done front panel repair on this model and have insight into the I2C messages?  Does anyone have a broken MSO4000B series scope with a front panel board they don't need?

[mikehank]

Hello,
It looks like the front panel microprocessor FW is corrupt and the mainboard is trying unsuccessfully to reprogram it or the microprocessor is bad.  I have seen this before.  It's the big square chip with a sticker on it(the part number on the chip is the Tek part number for the code programmed).  I would try to load the scope FW 1st and see if that will helps.  If that does not help a new front panel from somewhere else or a new programmed chip. 

[crhastre]

Does anyone have a broken MSO4000B or MSO5000B scope that they would be willing to part with the front panel assembly of?

[dbator]

Hi all,

I'm experiencing the same issue - what a coincidence. Well, maybe together we will solve the issue more efficiently. I hope you did not purchase a front panel board yet, since nothing is lost yet and they are not cheap. At least for my wallet they are too expensive.
Anyway, I would suggest you to provide more information and also you might wanna read my topic which could give you a clue what else can be checked and probed. You may want to skip first part related to boot issue as it is not relevant in case of front panel issue. Second part of my topic is related to front panel issue and all the details I know and remember/was able to document about front panel issue are there.
https://www.eevblog.com/forum/repair/tektronix-mso4054-no-boot-not-working-front-panel/

In your case the scope maybe is automatically booting because front panel microcontroller at U1 maybe reads pushed Power button which is not the case. Unless stucked button may cause I2C communications failure. Less possible I would say. Would be the firmware working that way? I assume you checked whether the Power button is not stucked.
I don't know which level shifter you mean. There is no such IC on front panel board unless you mean the acquisition board. According to datasheet of PCA9515A it is a bus repeater and I don't read it can shift levels. But it's not important in this case, since I2C bus is working properly.

If anyone could try readback that front panel microcontroller firmware, it would be great. You can spare your efforts asking Tektronix support because I already went that way without any success. Not that I thought they will make an exception.

[joebot5]

I have a similar issue with my MDO4104-6 scope. https://www.eevblog.com/forum/repair/tektronix-mdo4104-6-front-panel-microcontroller-failure/

Tektronix wasn't able to help. Essentially like most of these posts, if the program can be made available, then issues like these might be able to be resolved.

I found on ebay this front panel PCB available:
https://www.ebay.com/itm/285380453970?itmmeta=01J48M63KEGK1975620XK1DSSG&hash=item4272002652:g:DLoAAOSwXsViedvr

Maybe it would work with your scope?

[dbator]

Hi all,

please be patient and do not spend money for front panel, repair costs or for anything else, as I am already working on a solution. Due limited amount of time, I can't spend that much time I would, but the chances I will solve the issue soon are at about 95%. All the details and eventual questions will be provided as soon as it's possible.

[dbator]

Hello,

I think, in your case GPIO of front panel MCU controlling AC signal has incorrect state causing the scope is powering on immediately after power cycle. You already confirmed that master CPU on acquisition board can't communicate to slave CPU on front panel via I2C bus. Reason for that is either corrupted program stored in FLASH or faulty MCU. I know it's not convenient and riskily, but you have to go through following:
Probe front panel MCU reset - it should go low after power cycle.
Probe crystal - its frequency will probably be 32.768 KHz.
It doesn't hurt to probe supply voltage rails.
If the crystal is not working and you will not confirm any voltage at its pins (I don't remember, but the level may be around 0.5 Vpp) you have to confirm whether program is corrupted or the MCU is faulty. The type of microcontrollers do not fail just so easy, so I would say there is something wrong with the program.
You can confirm that buy trying to read or debug the program using dedicated hardware and software (PE Micro and CodeWarrior v6.3) or hardware and software of your choice. Any not officially dedicated hardware and software may be not completely compatible causing problems, so you will be using such on your own risk.
You may also just re-program the MCU using hardware and software of your choice.

I attached S-record file extracted from the firmware package for MSO4000B series. The file is called as usually, route66_fp.s19. If a software and programming device you will be using does not accept S-record files you have to convert it. There are apparently dedicated applications for such conversions. I did never found any and did not use any at all. It is possible to manually convert the S-record file to hex of course, but it's time consuming to convert each line of the script.
Note, in case of your model there is also a file called route66b_fe.s19 I have no idea what is the purpose of the file. There may be a second HCS08 MCU (maybe on the acquisition board) in your case for which the program is desired. Or there are just two files and the right one is used depending of an unknown factor at the moment of knowledge I have. One thing is sure, the script lines in both files indicate exactly the same FLASH address range.
Maybe there is someone who has the knowledge. Since I do not own a MSO4000B series scope, I can't investigate it. Maybe you will be the one who figures it out.

I am asking you to upload here the backed up program because I am curious of its content.

Should you have problems obtaining proper hardware and software or at programming of the MCU, I could try to reprogram your front panel board for free if shipping cost to Europe and back would be not a problem for you. I trust only, it will be electrically checked first (checked for shorts, supply voltage rails, XTAL/EXTAL of MCU etc.). Normally there are of course customs charges, but as far I know if is something is sent for repair and you inform customs it will be returned to you let's say within a month of six months (a guess), they should not charge as usually or at all.
It's a bit complicated though and there are additional shipping costs, so I suggest you to try to manage it by yourself first.

I attached route66_fp.s19 and route66b_fe.s19 files extracted from the firmware package. I added *.txt extension to be able to upload the files here. You have to remove them in order to use them.

More information and everything what I went through while investigating issue on my front panel is written under my thread there, which I recommend you to read:
https://www.eevblog.com/forum/repair/tektronix-mso4054-no-boot-not-working-front-panel/msg5626077/#msg5626077

If you have any questions, please feel free to ask. My setup is still not disconnected in case you have any questions and you want me to check something for you.

Good luck!

[crhastre]

I've been attempting to replicate your analysis using CodeWarrior 6.3 and the PE Micro Multilink Universal but haven't been able to establish BDM communication with the processor.  I've attached what I see in hiwave.exe when I attempt this.

I'm seeing activity on the BDM pin when I hit the Connect(reset) button, but I'm not seeing the debugger toggle the reset pin at all.  Should it be toggling that pin as well?  The datasheet seems to imply that BDM communications must be established immediately after exiting the reset state so I was expecting to see it resetting the processor.

Do you have any idea what I'm missing in the debugger setup?

[dbator]

That's how it works. [Connect (Reset)] asserts reset to target. BDM line is a command line of which state depending on how soon or late it is toggled (time relation to reset I think) 1 or 0 is output result. If it's High-Z, then the target has control over the line. At least that's how I understand it. So it's not that easy to say that what exactly is happening on the BDM in your case is correct or not. I think it's not worth to analyze it at this moment anyway.

You already confirmed correct BDM wiring, correct supply voltage (I hope you measured it on the board), both debugger LEDs being on. You confirmed however missing reset signal on BDM line.
I did not check how it works in my case and I am not able to do that since I currently have no second scope, but I think reset line should go high and then low for a short period of time in miliseconds, but only if Vref (target power) is detected. There's an option to set a delay while connecting to the target. It did never help me out if I experienced problems with connecting to the target, but it doesn't hurt to try let's say something between 50 and 250 ms.

There may be something wrong on the front panel board (electrically) the debugger is faulty or its cable is faulty. If you're allowed to do that you may try to carefully open the case and check the cable for connectivity - especially the reset line. Remember about ESD precautions.

Another possible issue is relation to operating system you're using. I could eventually try to install CW IDE on computer with Windows 7 installed, but you probably use Windows 10 or later. Although I don't think it could cause such issues.
Please upload a picture of your setup. Maybe a wire on your cable does not go completely into the debugger plug?

Additionally, did you actually specify the target? Please see attached screenshot.

[crhastre]

With help from dbator I was able to get this front panel repaired and the scope up and working again.

The problem I was having with the debugger toolchain was due to the fact that P&E released the multilink universal after the 6.3 release of CodeWarrior for HCS08.  P&E does have a patch available that can be found here: https://www.pemicro.com/faqs/faq_view.cfm?id=211&menu_id=faqs

It's non-obvious that the patch is needed because CodeWarrior doesn't give any indication that there is a problem with communication to the debugger itself, it just fails to connect to the target.

From a hardware standpoint, on the B revision front panel assembly, the non-populated J302 connector is the BDM port.  In my case jumper resistors R306 and R305 needed to be installed to make the connections between the micro and the BDM port.

Once I got connected to the micro, hiwave.exe reported that the micro had been secured and I was unable to read the FLASH contents.  It also appeared that whatever code was on the micro wasn't executing as nothing would happen when I hit "Run".  I used the Advanced Programmer Mode to erase the FLASH on the part and reprogrammed using the route66_fp.s19 file from the firmware upgrade package.  With this code loaded the front panel works correctly and the scope boots up without any front panel error reports.  Interestingly the micro is no longer secured and debugging from hiwave.exe is now functional.

[dbator]

It looks like even if I went the hard way through and was thinking now with all that knowledge I collected everyone should encounter no obstacles and repair easy their front panels, it turned out Tektronix must had complicate things even within the same series of scopes. Well almost the same - B and non-B can perhaps be considered as different series.

So:
1) No crystal at front panel MCU on this scope - internal clock as source is used.
2) No BDM connector and no jumper resistors populated on the PCBA - as if Tektronix covered up the tracks, so one does not think it is possible to access the MCU externally (or the board is used on different models, where in some the components are populated or in other they are not populated). I wonder, whether they removed the components after programming or they just used an external programming device. Good job at figuring out that missing components can be populated.
3) MCU was secured. Unless it is possible to get the MCU secured by installation of any application module because I suspect, front panel MCU manages the application modules slots. Maybe via SPI. I will try to trace the lines before I assembly my scope back and will let you know.

The possible reason why the MCU is no longer secured after programming it with route66_fp.s19 is either difference between the files (the file extracted from the package may not consist of security on purpose due complexity of securing the MCU via I2C, less possible) or executed program does secure the device which you didn't notice since you didn't run the code after programming. Or did you?
According to the datasheet of MC9S08AW32, the MCU has the security set by default after FLASH erase, so the manufacturer recommends to unsecure the blank device by setting proper bits before programming it in case no protection will be used.

Anyway, now we know, there are big chances for any of us by simple re-programming of the front panel MCU on the DPO4000/MSO4000/MDO4000 series of scopes with file extracted from firmware package with firmware package that can be downloaded from Tektronix support website. I hope joebot5 will be able to repair their front panel too that way.

I wonder why the program in FLASH gets corrupted that easy? Do you remember in which circumstances the issue occurred? Occurred it after firmware update?
And what is the route66b_fe.s19 file for? Debug log from your scope consists of something interesting:

Code: [Select]

feReprogramFeProc: Platform Route66b fw 1028 filefw 1028
 Front Panel Firmware update not needed
   Current firmware 1028 >= 1028
That's the route66b_fe.s19 file which is indicated there. It is also called front panel firmware and it seems to be up to date. Then master CPU on acquisition board attempts to communicate to the salve CPU (front panel MCU) and fails.
Well, maybe someone of us will find out someday what is the purpose of that file.

[daveyk]

I love MSO4104 (no-B); it is my favorite scope (I have too many TDS3000 series scopes - lol).  Lately it has been having issues responding to certain front panel buttons (i.e. Magnifying glass, but most importantly the second button from the left under the display).  One of the other button right of it has problems to.  I need to keep this scope ISO17025 calibrated and not sure if there is a repair facility that could handle it. 

I then found out that unplugging the USB cable, in the back, seems to have cured the issues.   I use that interface to control the scope and get data from it with a lot of programs I use on a daily basis.  Remote control via that port works perfectly.  I have not tried via the network port; I'm not sure I should let the scope on my network and my test computer only has one network port.

Anyway, with the USB unplugged from my test computer, the front panel seems to be working fine, so I am sure I can send it out for ISO17025 calibration in October.  Don't laugh, but I swear this started after a Wiondows 11 update a month ago.



Using the scope for trouble-shooting with a flakey front panel is impossible. So, I just haven't used the MSO4104 for trouble-shooting lately because of this. 

This issue started a couple of months ago and I am not sure how to proceed, or if I should, and just live with it the way it is.