MSOX3014A PSU and infinite reboot loop – possible NAND issue? - Page 1
Forum section: electronics / repair

author: NorwegianRF
author_rank: Contributor
timestamp: May 10, 2025, 01:41:56 am
content: Hi,I came across an MSOX3014A with a broken power supply, which I understand is quite common. Before ordering a replacement (Murata PQC250-12), I tried powering the scope using an external 12 V supply. However, the unit enters an infinite reboot loop — see the attached video:Could this behavior be caused by a faulty NAND chip, or are there any other known issues that could cause this? I’ve logged the current draw, and it doesn’t exceed 3.5 A during a boot cycle.Any tips would be greatly appreciated!Best regards,Stian

author: xrunner
author_rank: Super Contributor
timestamp: May 10, 2025, 02:03:45 am
content: You shouldn't post the same thing in two different boards.

author: NorwegianRF
author_rank: Contributor
timestamp: May 10, 2025, 02:10:48 am
content: Thanks for the reply, I have removed the other post.

author: Kean
author_rank: Unknown
timestamp: May 10, 2025, 01:12:26 pm
content: Quote from: NorwegianRF on May 10, 2025, 01:41:56 amI would be suspicious about this. Is your external 12V supply able to handle peak currents of more than 3.5A?If the external supply goes into current limiting, then the drop in voltage could cause a reboot loop and you may not see a current over 3.5A however you are measuring it.Or if you don't have enough connecting wires (or they are too long) the voltage drop at high current again could be the issue. I see a pair of thin red/black wires at the left of the scope in your video.The CCH0125F1-Z03A PSU is rated for 100W, and I recall some mentions of typical draw in some of these scope models being 50+W. It would make sense that an MSOX3000 model would draw more than say the DSOX2000.

author: NorwegianRF
author_rank: Contributor
timestamp: May 10, 2025, 03:24:38 pm
content: I've tested with doubled-up wires, and the power supply shouldn't be the limiting factor — it's a fairly powerful unit. There's no observable voltage drop when the scope begins to reboot either.What I'm a bit concerned about, though, is whether the scope might have been damaged when the original PSU failed.I suppose the next step is to hook up a serial connection to the mainboard and see what it outputs during boot.

author: NorwegianRF
author_rank: Contributor
timestamp: May 10, 2025, 08:47:18 pm
content: Attached is the serial output captured during the boot/reboot cycle

author: Kean
author_rank: Unknown
timestamp: May 11, 2025, 02:23:38 pm
content: It seems to be rebooting at the same spot each time.I'd suggest looking for a boot log posted by someone else and see what comes after the keyboard detection. That may give a hint where to look next.

author: NorwegianRF
author_rank: Contributor
timestamp: May 12, 2025, 08:29:08 pm
content: Update: It’s alive! Unplugged the front panel, and it boots right up. I still need to track down the issue with the keyboard moduleUpdate:Just wanted to follow up with what I’ve found so far.'mtest' in U-Boot still consistently fails when testing the DDR1 region (0x80000000+), but passes without errors in the internal SRAM area (e.g., 0x04000000).Both NAND images verify correctly using the bootloader image menu (v option).Edit:This means that even if I can’t use mtest to test the DDR, the bootloader’s verification process still writes to the same DDR address, reads it back, and verifies it successfully — correct?I’ve dumped the full NAND contents via UART, and the image data appears intact and matches expected structure.2.5 V is present at the VP2V5 test point on the mainboard, and also on a via close to the RAM chip, but I haven’t been able to confirm whether it actually reaches all relevant "BGA" pins.Has anyone encountered similar symptoms on these scopes, or found a definitive way to verify whether the DDR1 chip is physically damaged vs. just not being properly initialized or powered?Thanks in advance for any insight.

author: tom66
author_rank: Super Contributor
timestamp: May 12, 2025, 09:45:46 pm
content: It's kinda bonkers to me that people are still building software based on Windows CE in 2021, but there you have it.Does mtest fail at the same address every time in DDR1? It might be that only DDR0 is initialised, since it only has 128MB of RAM. It looks like kernel is loaded into 0x00000000 which is typical address for DDR0 base. You'd want to check the devicetree for u-boot, which is usually part of the root filesystem, and called system.dtb, to find out the exact memory mapping. If you have a dump of the NAND, you should be able to locate it by searching for "0xd00dfeed" (the DTB signature). Hopefully the file is contiguous, you may have to experiment to extract it all.It looks to die around the time the FPGA initialises, so I wonder if there could be a problem with one of the power supplies around it that when enabled, pulls something down. But, just a guess. Maybe you can interrupt the FPGA loading by modifying the image filesystem. It won't -work-, the scope will almost certainly be bricked without the FPGA, but it would prove the idea out and allow further diagnosis.

author: pepona
author_rank: Contributor
timestamp: May 13, 2025, 07:33:53 pm
content: Quote from: NorwegianRF on May 12, 2025, 08:29:08 pmHi Stian, could you share the commands to create the dump via UART?Thanks, Marcos.

author: NorwegianRF
author_rank: Contributor
timestamp: May 14, 2025, 06:58:52 am
content: I used this Python script to perform a full dump of the NAND flash memory, but be aware that it takes several hours to complete.

author: pepona
author_rank: Contributor
timestamp: May 14, 2025, 01:48:07 pm
content: Ok, I'll try it. Thanks a lot.Best regards...Marcos.

author: NorwegianRF
author_rank: Contributor
timestamp: May 15, 2025, 09:18:48 am
content: The hunt continues:I have verified that the VP13V_PRB (AutoProbe supply) does not stay at 13 V when the keyboard cable is connected, and the scope boots fine when it's disconnected. According to the service manual, this indicates that the keyboard module must be replaced.Tracing the 13 V rail on the keyboard PCB, it supplies both an LM2940CS and an LT3580 circuit. I tried disconnecting the VIN pin of the LM2940CS, but the 13 V rail still fails to come up during boot. I now suspect the LT3580, which generates a negative voltage, might be the culprit — or at least something in the negative supply chain.Has anyone seen failures related to this circuit before?

author: tom66
author_rank: Super Contributor
timestamp: May 15, 2025, 10:04:31 am
content: I wonder if someone put something on the active probe power supply that they shouldn't have. I would check the LT3580 is not shorted, and also any protection components on the output (if any are present). Also might be worth seeing there is a shorted ceramic capacitor.

author: NorwegianRF
author_rank: Contributor
timestamp: May 15, 2025, 10:37:38 am
content: tom66, I do believe you're onto something. I found this tell-tale sign on one of the probe inputs.It's between pin 1 and 2, which are:1 +3 V to +6 V (adjustable via resistor on pin 7)2 −3 V to −6 V (adjustable via resistor on pin 7)When measuring the resistance to ground from both the positive and negative power rails, the resistance isn't low—but I guess the LT3580 could still be the cause. I think I'll try removing VIN from it and see if I can get the 13 V rail stable and the scope to boot up with a functional keyboard.I'm not 100% sure, but hopefully the encoders and buttons will still work without the ±12 V power rails, as it looks like they only relate to the AutoProbe functionality.

author: tom66
author_rank: Super Contributor
timestamp: May 15, 2025, 11:32:05 am
content: I would imagine the encoders are going to be driven from 3.3V or 5V, probably the same supply that lights the LEDs up - so hopefully it is all OK as that still works.

author: NorwegianRF
author_rank: Contributor
timestamp: May 19, 2025, 06:13:50 am
content: I have removed both the negative and positive 12 V regulators, and when observing the +13 V line with an oscilloscope, I can see it rise to 13 V and then slowly decrease, as if it’s being intentionally shut down. This suggests there is no excessive load on the circuit causing the voltage to collapse.One interesting thing I noticed: when I "load" the 20 MHz crystal for the MCU on the keyboard board (so that it doesn't oscillate), the scope doesn't reboot — but instead hangs during boot.This makes me suspect that the keyboard board might be actively reporting a fault condition to the mainboard.Unfortunately, there's no detailed troubleshooting procedure available for the keyboard board — only a generic note saying it most likely needs replacement.I've identified one pin on the MCU that clearly transmits data. I’ll try to probe that and see what it’s sending.

author: Kean
author_rank: Unknown
timestamp: May 19, 2025, 07:04:05 am
content: Stuck button maybe...