| Products > Test Equipment |
| Agilent MSOX4054A repair (NAND corruption issue) |
| (1/7) > >> |
| hotacid:
Hi folks! Longtime lurker here coming out of the dark :) I recently acquired a used MSOX4054A scope from an auction only to find it doesn't boot when I try to turn it on. The unit is in great shape so I don't suspect anything physical has damaged it. This is what happens: 1. I push the power button to the "on" position. I hear the fan turn on. 2. The front panel LEDs all turn on and off again once very briefly 3. About 1s later, the "Ref" button LED turns on and stays solid 4. About 1s later, the "Math" button LED turns on and stays solid 5. About 3s later, the "Digital" button LED turns on and stays solid 6. Nothing more happens past this. The scope stays stuck forever After hours of searching the web on this issue, I came to understand there is a known issue with the 2000X/3000X/3000T/4000X series scopes where the main NAND becomes corrupted over time and this prevents the unit from booting. The descriptions of other peoples issues sounds very similar to my units behavior so I suspect I have the same problem. I found some mentions of Keysight fixing this problem for free so of course I tried that path first... a week later and several emails + phone calls later, Keysight told me that it won't be covered for me and wouldn't give a reason why. Strangely, the applications engineer I spoke to was also surprised that it wasn't covered but even a 3-way call with him and the repair department didn't help. They wanted $4500 USD so I politely declined. :-- So now I'm trying to fix this unit at home. Fortunately, there is a quite helpful thread about hacking these series of scopes which contains very valuable information on how to potentially repair this thing. Yes, I read all 97 pages. https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/ I've gotten the unit apart and I have access to the serial connection from the SPEAR600-2 CPU. A serial log of the unit booting seems to all but confirm some memory corruption has occurred. Here's a snippet of the serial output (full log attached). --- Quote --- Loading image 1 from memory at 0xD0400000 O BL_IMAGE_TYPE_BIN X XXXXXOOOOXXOOOOOOOOXOXOXOOOOOOOXOOXOXOOOOXXOOOOOOOOOXOOOOXOXOOXXXOOOXOXXXXOOXXOXOOOOOXOOXXXXOXXOOOXOOXXOXXOXOOOXOOXOOXXOOOXOOOOXOXOOOOOXOOOXOOXOXXOXOXOXOXXXXXXOXXXXXOOOOXOOXOOXOOOOXOOOOXXOXOOOOOOOXOOOXOOXOOOOXX OOOOOXOOXOOXOXOOOOOOOOOXOOOOXOOOOOOXOXOOOOXXOOOOOOOXOOOOXOOXOOOXOOOXOOXXOOXOOXOXXOXOOXOXOXOXOOOXXXOOXOXXOOOXXXXOXOOXOXOOOOXOOOOXOOOXOOXOOXOOOXOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXXXXXXXOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOIncorrect Data 0 EccResult: 566556 EccError: ff3c3c EccRead: a9596a EBOOT_ReadFlash failed offset 204eb88 EBOOT_ReadFlash failed location d2054000 ODeCompressFlash: CeCompressDecode() failed CeDecompressFlashBlock failed ****** Data record 146 corrupted, ABORT!!! ****** --- End quote --- I've been following along the footsteps of one user (titiris - thank you!) who reported he was able to fix his NAND corruption by transferring the unpacked firmware kernel image 'nk.nb0' to the scope over the serial connection (using YMODEM mode), booting the image, which then boots from an external USB drive. Once the Infiniium software is up and running, a normal firmware update procedure can be carried out through the scope GUI to repair the damaged files. His explanation is here: https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg2136181/#msg2136181 However, I'm hitting an issue with this method. It seems that the YMODEM image transfer always stops abruptly when it gets to ~75% complete. No error messages or warnings are printed. I also tried following along Frankbuss's method by using TFTP but this hits the same issue... the transfer is working fine until 61466628 Bytes are transferred (out of 81508824 Bytes total) and then it just stops. It looks like the unit is hanging. Is the image too big and the scope ran out of memory? I'm not sure what is going wrong. https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg260917/#msg260917 Has anyone tried this on a 4000X series scope? Any suggestions would be greatly appreciated! |
| TheSteve:
I've never had the chance to try repairing a 4000x series, only the 2000/3000. Your file does seem large though compared to the ones for the 2000/3000. I dream of finding a corrupted 4000x(or even 6000x) series some day for a great price. |
| hotacid:
Yeah the image size is about double that of the 2000/3000 series. But the instrument must have enough RAM to hold the transferred image, right? I'll see if I can split the image in two and do two transfers. Another problem I have is that I can't find the old firmwares for this scope. It was mentioned in titiris' guide that the firmware version I transfer over to the unit has to be similar to the (corrupted) one on the NAND, or the boot may not get far. If anyone has one sitting on their machine, I'd love to get my hands on it! Here's a complete list of the firmwares. I have only managed to find 7.30 and 4.08 from searching the internet. File Name Release Date Instrument Software Version4000XSeries.7.30.2019051435.ksx29 May 20197.30.20190514354000XSeries.7.20.2017102615.ksx26 Oct 20177.20.201710264000XSeries.7.11.2017061227.ksx12 Jun 20177.11.201706124000XSeries.7.10.2017042903.ksx29 Apr 20177.10.201704294000XSeries.07.10.2017041132.ksx11 Apr 20177.104000XSeries.04.08.2016071801.agx27 Jul 20164.084000XSeries.04.07.2016040802.agx20 Apr 20164.074000XSeries04.05.2015051200.agx27 May 20154.064000XSeries04.05.2015021000.agx16 Feb 20154.054000XSeries.04.00.2014101303.agx01 Nov 20144.004000XSeries03.22.2014052101.agx21 May 201403.22.20140521014000XSeries.03.21.20140110001.agx21 Jan 201403.21.201401100014000XSeries.03.20.2013082300.agx03 Sep 201303.20.20130823004000XSeries.03.12.2013041700.agx23 Apr 201303.12.20130417004000XSeries.03.11.2013030100.agx01 Mar 201303.11.20130301004000XSeries.03.10.2013020700.agx12 Feb 201303.10.20130207004000XSeries.03.01.20121212001.agx12 Dec 201203.01.201212120014000XSeries.03.00.201209XXXX.agx?? Sep 20123.00 |
| TheSteve:
With a 2000/3000 the firmware you transfer over does need to be the same version on the scope or very close or it won't boot all the way(or at all). Is the scope Agilent or Keysight branded, you can use that to give you a hint of a version to try. I have no 4000x series firmware myself. I still am wondering about the image you're using, I don't think it should be double the size. |
| hotacid:
--- Quote from: TheSteve on January 14, 2020, 07:15:24 am ---With a 2000/3000 the firmware you transfer over does need to be the same version on the scope or very close or it won't boot all the way(or at all). Is the scope Agilent or Keysight branded, you can use that to give you a hint of a version to try. I have no 4000x series firmware myself. I still am wondering about the image you're using, I don't think it should be double the size. --- End quote --- Yes, I'm quite worried that will be the case when I do figure out how to transfer it. The scope is Agilent branded. Looking at its service history, Keysight performed a repair (the scope wouldn't fully power on!) by replacing the acquisition board and calibration on Feb 11 2015. There is also an interesting note that says the owner declined to have Service Note MSOX4054A-02 completed around the time it was being repaired. This service note is recommending a firmware upgrade if the version on the instrument is 3.11 or older. The fact that the owner declined a firmware update in 2015 makes me think it was probably not updated past this point. So the scope may have an ancient 3.11 or older version on it... not good. I think 80MB is correct because the "Declassification of the InfiniiVision X-Series Oscilloscopes" document you can find online shows the Windows CE portion being this large. Splitting the image in two didn't work. The first transfer was fine (41943040 bytes) but the second transfer hit a hang after byte 19522932 had been transferred. I also tried placing it in at a different starting address in memory (0x0 instead of 0x361000) but this likewise hit a hang after 65010380 bytes. |
| Navigation |
| Message Index |
| Next page |