Tektronix MSO4000B Front Panel Repair - Page 1
Forum section: electronics / repair

author: crhastre
author_rank: Newbie
timestamp: May 29, 2024, 06:50:38 pm
content: 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:U-Boot 2009.08 (Mar 03 2011 - 17:01:14) Tektronix, Inc. V1.01CPU: AMCC PowerPC 460EX Rev. B at 600 MHz (PLB=200, OPB=100, EBC=50 MHz)No Security/Kasumi supportBootstrap Option F - Boot ROM Location I2C (Addr 0x54)Internal PCI arbiter disabled32 kB I-Cache 32 kB D-CacheBoard: Tektronix Route66B AMCC 460EX Main Board PVR 130218a4VCO: 1200 MHzCPU: 600 MHzPLB: 200 MHzOPB: 100 MHzEBC: 50 MHzProgramming SDIA...doneI2C: readyDRAM: Auto calibration -\ \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/ 512 MBFLASH: 128 MBPCI: Bus Dev VenId DevId Class Int00 0d 1172 0004 ff00 18In: serialOut: serialErr: serialBoard version: 1 (Proto) 4 channel MSOI/O board version: 3SDIA version: 0133Calibrating VCO...doneNet: ppc_4xx_eth0Enter 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 f8040000Verifying Hash Integrity ... crc32+ sha1+ OKBooting using the fdt blob at 0xf824a230Uncompressing Kernel Image ... OKLoading Ramdisk to 1f130000, end 1f1ff5e6 ... OKLoading Device Tree to 00ffa000, end 00fff0d0 ... OKChecking 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 2012Scope application starting (normal mode)---------------------- startScopeApp() running Init code ----------------------versionBuildFWVersionString(): TimestampString: 15-Nov-12 14:28VersionFIRMWAREVERSIONversion: v2.90Major ver num: 2 Minor ver num: 90Initializing SdiaMain Board HW Rev: 0x09Initializing Tek0005Initializing Ibm460feReprogramFeProc: Platform Route66b fw 1028 filefw 1028Front Panel Firmware update not neededCurrent firmware 1028 >= 1028Initializing HFD204ADCInitializing HFD204ADCMain Board HW ID: 0x02AFE Board SW ID: 0x02Main Board SW ID: 0x05Initializing Ad5668DacInitializing Ad5668DacInitializing Adt7476HFD144 ID_REG = 0x00001440HFD144 ID_REG = 0x00001440HFD144 ID_REG = 0x00001440HFD144 ID_REG = 0x00001440Initializing Hfd144Initializing Hfd144Initializing Hfd144Initializing Hfd144Initializing AfeInitializing MDOInitializing Adf4350Initializing Tek026Initializing Tek026Initializing Tek026Initializing Tek026Initializing Tek026Initializing Dac5571Initializing Tmp421Initializing Tmp421Initializing Tmp421Initializing Tmp421Initializing Tmp421Init ADT7476.ialInit(): AFE id 0x2, rev 0x4, bI 14104B-L with bI 10Factory Checksum: Stored: 39002, Calculated: 39002 - OKSpc CheckSum: stored: 31340 calculated: 31340 - OKDemux initializationDram calibrationDram calibration completeDram Calibration results:-------------------------DramCal has PASSED on all DemuxsDemux initialization completeStarting POST diagsFinished POST diags1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O errorERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.firmware version read: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O errorERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.platform version read: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O errorERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 2 bytes - got -1 bytes.common code version read: Remote I/O errorInstalling 44 in front panel.fpReprogramFrontPanelCpuPrivate(/usr/local/perm/route66_fp.s19)fpSRecCheckSum returning 0fpSRecRaw: FP_UPDATE_CODE_START_CMD write failed - -1 bytes of 3 writtenReprogram start: Remote I/O errorFp software update function reports failure.1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O error1st purge loop: Remote I/O errorERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.firmware version read: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O error2nd purge loop: Remote I/O errorERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 3 bytes - got -1 bytes.platform version read: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O error3rd purge loop: Remote I/O errorERROR in fpSharedPrivate.cpp at fpReadFpHwAndSwIdAndVersion: IIC requested 2 bytes - got -1 bytes.common code version read: Remote I/O errorAfter Fp software update version is -1, expected 44.fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O errorbytes 3 - 0x6 0x0 0x1bytes in queue 0---------------------- startScopeApp() running Start code ------------------------------------------- startScopeApp() running Run code -----------------------fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O errorbytes 3 - 0x6 0x0 0x2bytes in queue 1fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O errorbytes 3 - 0x6 0x1 0x2bytes in queue 0-----------------------------------------------------------------startScopeApp() complete; duration = 24.305649 seconds=================================================================PID to Task info written to /tmp/threads.txtPower Up Completed at 00:15:36Enter 'ctrl-\' to quit scopeApp00:15:36 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:36 bytes 2 - 0x2f 0x1bytes in queue 000:15:36 SocketServerService: Socket server daemon started on port 4000.Protocol: Raw00:15:36 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:36 bytes 2 - 0x2e 0x4bbytes in queue 000:15:37 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:37 bytes 3 - 0x6 0x0 0x2bytes in queue 0Failed to kill daemon: No such file or directory00:15:37.381.889 usbtmc488_enable_interface: USBTMC enabled; response buffer size = 261648Failed to kill daemon: No such file or directory00:15:37 SDIA version 0x133, non-Trinity, skip calSdiaRunClkSync()00:15:41 Run Sync Cal - PASSED00:15:41++++++++++++++++++++++++++++++++++++++++++++ adc Interleave cal - Powerup+++++++++++++++++++++++++++++++++++++++++++00:15:41 cfg 4, chMask 0x900:15:41 srcChId 0, adcMask 0x30, numPipes 2:00:15:41 Loop 0, MeasuredFreq = 9.522944e+0600:15:42 Loop 1, MeasuredFreq = 9.523233e+0600:15:42 Loop 0, MeasuredFreq = 1.333326e+0800: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+01ps00:15:42 + totalPhaseAdjust = -1.085336e+03 ps00:15:42 + Adc_5 phaseErr: actual 4.91e+00ps, exp < +/- 2.00e+01ps00:15:42 + totalPhaseAdjust = 1.113485e+03 ps00:15:42 +++++++++++++++++++++++++++++++++++++++++++++00:15:42 cfg 5, chMask 0x900:15:42 srcChId 3, adcMask 0xC0, numPipes 2:00:15:43 Loop 0, MeasuredFreq = 9.523178e+0600:15:43 Loop 1, MeasuredFreq = 9.524544e+0600:15:43 Loop 0, MeasuredFreq = 1.333321e+0800: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+01ps00:15:43 + totalPhaseAdjust = 4.981936e+02 ps00:15:43 + Adc_7 phaseErr: actual -7.39e-01ps, exp < +/- 2.00e+01ps00:15:43 + totalPhaseAdjust = -5.077606e+02 ps00:15:43 +++++++++++++++++++++++++++++++++++++++++++++00:15:43 Power On Interleave Cal - PASSED00:15:43 ********************00:15:43 * Power up Deskew *00:15:43 ********************00:15:43 calPowerUpDeskew: sampleInterval = 4.000000e-10, sampleRate = 2.500000e+0900:15:43 midCrossTweak = 0.0000:15:47 tgDacLvl = 2310.200:15:49 adc4 skew -2.976953e-08 currentPhase -1.313717e+01 phaseFrac 8.628321e-0100:15:49 adc5 skew -2.997363e-08 currentPhase -8.150372e+00 phaseFrac 8.496277e-0100:15:49 adc6 skew -3.054785e-08 currentPhase -1.112415e+01 phaseFrac 8.758533e-0100:15:49 adc7 skew -3.075996e-08 currentPhase -1.416930e+01 phaseFrac 8.306987e-0100:15:52 avgMidCross = 5.000821e+03, skew = 3.285156e-10s, adcMask = 0x1000:15:52 ChIdx_0 skew 3.285156e-10 refSkew -7.148437e-11 phaseBump 1.00000000:15:52 avgMidCross = 5.000842e+03, skew = 3.369141e-10s, adcMask = 0x2000:15:52 ChIdx_1 skew 3.369141e-10 refSkew -7.148437e-11 phaseBump 1.00000000:15:52 avgMidCross = 5.000841e+03, skew = 3.365234e-10s, adcMask = 0x4000:15:52 ChIdx_2 skew 3.365234e-10 refSkew -7.148437e-11 phaseBump 1.00000000:15:52 avgMidCross = 5.000825e+03, skew = 3.300781e-10s, adcMask = 0x8000:15:52 ChIdx_3 skew 3.300781e-10 refSkew -7.148437e-11 phaseBump 1.00000000:15:52 Power Up Deskew Cal - PASSED00:15:52 Power Up DeskewRf Cal - PASSED00:15:52 calSetPowerupAdcPhaseValues chMask = 0xF00:15:52 Mss Trigger Cal00:15:52 Mss Trigger Cal - PASSED00:15:52 Last Cal'd facVersion: 5, current facVersion 500:15:52 Last Cal'd SpcVersion: 3, current SpcVersion 300:15:53 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:53 bytes 2 - 0x2e 0x4bbytes in queue 300:15:53 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:53 bytes 2 - 0x2b 0x2bytes in queue 200:15:53 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:53 bytes 2 - 0x2a 0x2bytes in queue 100:15:54 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:54 bytes 2 - 0x2e 0x4bbytes in queue 000:15:54 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:54 bytes 3 - 0x6 0x0 0x1bytes in queue 100:15:54 fpSendCmd: queued I2C write error on second attemp -1fpSendCmd queue: Remote I/O error00:15:54 bytes 3 - 0x6 0x0 0x2bytes in queue 0If 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 fromhttps://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?

author: mikehank
author_rank: Regular Contributor
timestamp: May 29, 2024, 09:51:26 pm
content: 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.

author: crhastre
author_rank: Newbie
timestamp: June 03, 2024, 03:43:51 pm
content: Does anyone have a broken MSO4000B or MSO5000B scope that they would be willing to part with the front panel assembly of?

author: dbator
author_rank: Contributor
timestamp: June 22, 2024, 07:34:58 pm
content: 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.

author: joebot5
author_rank: Contributor
timestamp: August 02, 2024, 04:05:57 am
content: 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:DLoAAOSwXsViedvrMaybe it would work with your scope?

author: dbator
author_rank: Contributor
timestamp: August 07, 2024, 04:03:57 pm
content: 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.

author: dbator
author_rank: Contributor
timestamp: September 01, 2024, 02:55:58 pm
content: 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/#msg5626077If 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!

author: crhastre
author_rank: Newbie
timestamp: September 10, 2024, 02:58:51 pm
content: 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?

author: dbator
author_rank: Contributor
timestamp: September 11, 2024, 06:51:53 am
content: 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.

author: crhastre
author_rank: Newbie
timestamp: September 16, 2024, 12:48:26 pm
content: 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=faqsIt'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.

author: dbator
author_rank: Contributor
timestamp: September 16, 2024, 03:00:11 pm
content: 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:feReprogramFeProc: Platform Route66b fw 1028 filefw 1028Front Panel Firmware update not neededCurrent firmware 1028 >= 1028That'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.

author: daveyk
author_rank: Frequent Contributor
timestamp: September 29, 2024, 09:42:11 pm
content: 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.

author: dbator
author_rank: Contributor
timestamp: March 20, 2025, 08:36:11 pm
content: Hello,first, I was not aware someone replied to the topic - I did not received a notification even though the topic is on the list of notifications. It looks it does not work well.Now, it's really strange, but if you confirmed, the scope is working properly without USB connected to your computer, it looks like it's not related to hardware of scope.I'd suggest to connect the scope via USB to couple of other computers with different operating systems and see if the problem occurs too. If yes I would probe (using another scope or logic analyzer) for any suspicious behaviour (see whether there are differences before and after plugging in the USB cable. And also try the front panel USB by plugging in an USB stick, store something on it (settings, screenshots), then removing and again plugging it in and restoring stored settings from the USB stick.There's an USB power distribution IC on I/O board on my scope (MSO4054), so maybe on MSO4104 too. Mine was faulty. I don't know what were the symptoms because my scope was not booting at all and I replaced the IC (the +5 Volts was dropping fast after powering on of the scope), before I could get the scope running and the scope was purchased by me already as not booting.You could also check debug console log whether it shows something when plugging in the USB cable. It's probably not set to verbose mode and if not, you should know the password to get into the bootcode. I recall I tried different words. Unfortunately unsuccessful. There is something I would try, but my scope is already assembled.That's all I can think of now.

author: luiscircuits
author_rank: Newbie
timestamp: August 30, 2025, 04:52:36 pm
content: Hello.I´m reparing a MDO4104. It stop at Boot. The screen is splashed.I read a lot of comments but I didin´t find the way to diagnose It.Please, Could anybody to indicate how extract the Boot Log or how to connect a Serial Debug console port trace?

author: sprit
author_rank: Regular Contributor
timestamp: August 30, 2025, 05:50:21 pm
content: Hi luiscircuitsDid you check the voltage TP on the board? make sure the voltage is ok

author: dbator
author_rank: Contributor
timestamp: August 30, 2025, 06:05:16 pm
content: Hello,I see you did not try to search or you weren't successful at finding information you need. There are some threads here which will prepare you to the task. Every case may be different, so be cautious and do not act too fast.Details about debug console port you will find on that thread (page #2)https://www.eevblog.com/forum/repair/tektronix-dpo-4104-kernel-panic/Maybe on your scope will be possible to read the debug log via VGA port. I couldn't do that on mine MSO4054, but I read somewhere here on the forum, that someone did.Another thread:https://www.eevblog.com/forum/repair/tek-mso4104-no-boot/And that one is from me - if you have another scope for investigating the issue and eventually a thermal camera, that thread may be also helpful. You will read everything about I went through and learned. I still couldn't manage to upload the video showing re-programming of front panel MCU.https://www.eevblog.com/forum/repair/tektronix-mso4054-no-boot-not-working-front-panel/msg5856089/#msg5856089Good luck.

author: luiscircuits
author_rank: Newbie
timestamp: August 31, 2025, 04:57:42 pm
content: Thanks for your help, guys!!I will inform.

author: dbator
author_rank: Contributor
timestamp: August 31, 2025, 05:20:34 pm
content: Old Micron DRAMs fail that often, that I bet, you have a faulty one too. Try to warm up every single DRAM (one by one) with hot air set at not more than 50 degrees Celsius (122 degrees Fahrenheit) and air pressure set to the lowest possible value and power on the scope. Two of four of the DRAMs are unfortunately of front side of the board so you will be needing to power on the scope without fans - do not keep it powered on too long without cooling.Be careful! There is that damn metal front enclosure close to the mains connector on I/O board which can make a short circuit at mains input.