Agilent 54622D not booting - CPU keeps getting reset - Page 1
Forum section: electronics / repair

author: alexst
author_rank: Newbie
timestamp: May 17, 2020, 12:24:48 pm
content: Hi everyone,I've been trying to repair an Agilent 54622D that doesn't boot at all - all front panel LEDs stay on and nothing else happens.I originally tried the reset trick of holding down a softkey, but sadly it was not that easy.I've also swapped out the battery since the original one had been dead for a while.I've checked all the voltages and they seem to be in spec, and I had started checking clocks when I noticed something interesting:The 68k CPU gets reset every ~1.36us, at which point the 25MHz clock also skips a clock (resets?).I've attached a scope capture of the CPU's CLK (CH1) and RESET (CH2) lines (please excuse the horrible signal integrity, that's due to my dodgy measurement setup).The main 200MHz oscillator does seem to be oscillating properly and there's no dropout on the power rails that matches up with the resets.Another thing to note is this scope used to work until one day my finger slipped on the power button and I ended up powering it on, off, on in quick succession and it never booted since.This could be a giant coincidence, and my memory of the details is quite fuzzy since it was nearly 2 years ago, but I'm pretty sure that's what did it.I've been trying to trace the CLK and RESET signals on the board, but I can't seem to find where they're being driven from. I've managed to trace reset to a 5V pullup on a resistor array and the input of an AND gate they seem to be using as a buffer, but nothing that's driving it yet..The reset circuitry seems to be different from the HP 54601A schematics that are available, as they're using a TL7702 to do the reset there and I can't find anything similar on this board.I would appreciate any tips or suggestions on what to try next or where to look at, as I've hit a wall.Thanks!

author: SilverSolder
author_rank: Super Contributor
timestamp: May 18, 2020, 02:14:50 am
content: It is very annoying that no schematics are available for this model...Practically speaking, one way to deal with undocumented equipment is to get another one - a "known good" unit - to compare with. It might be possible to buy a cheap one on eBay and (a) use for comparison, and (b) use for spare parts. You would be fairly sure of getting a result that way.

author: giovannirat
author_rank: Regular Contributor
timestamp: May 18, 2020, 04:39:10 pm
content: Try to check the DTACK signal. It could be a memory problem, in that case IMHO a watchdog timer kicks in......

author: alexst
author_rank: Newbie
timestamp: May 19, 2020, 12:28:53 am
content: Thank you both for the replies!Technically I might be able to probe off of a working unit at work once the lockdown is over, but that will be far in the future..Unfortunately these scopes are a bit hard to find around here and get quite pricy; definitely an option on the table though.A memory problem isn't something I had considered but this definitely sounds possible, thanks!I'm not familiar with the 68k CPUs. I can see DSACK0/DSACK1 pins but no DTACK on this specific part (MC68EC020FG25).Nonetheless, I'm going to have a more detailed look at the datasheet and bus activity tomorrow and update this thread with my findings.I can see that the HALT and RESET lines are tied together.I was assuming that these resets must be caused by an external circuit but it sounds possible that it's the CPU itself doing this?

author: alexst
author_rank: Newbie
timestamp: June 19, 2020, 03:12:34 pm
content: It's been a month, and I wanted to update this thread with my findings so far.The CPU is indeed asserting its own reset via the HALT signal, I lifted the pin and tied it to reset via a resistor and can see it going low almost instantly - appears to be a double bus fault.My problem now seems identical tohttps://www.eevblog.com/forum/repair/hp-agilent-keysight-54621d-mso-repair/except mine seems to halt even quicker.The ADM691 supervisor is fine too, correctly timing the power-on reset. The CPU doesn't reset like this if it's held in HALT all the time.The inrush limiting NTC in the power supply blew up too, I guess the old part didn't like the repeated power cycles, but that was an easy fix.Everything does seem to point to a bad flash unfortunately.I found an unpacked image on the forums here:https://www.eevblog.com/forum/testgear/agilent-5462054640-series-unpacked-firmware-files/I'll grab a TSOP48 ZIF socket and take a look at the flash chips, the problem is that there are 4 of them at 8Mbit each.Two of them have stickers that say 54624-80003 and 52624-80004, two are unlabelled.Does anyone have any info on which one of these chips is the first one, and how the 1.6M image is split between them?Thanks!

author: SilverSolder
author_rank: Super Contributor
timestamp: June 19, 2020, 04:44:07 pm
content: You can download the latest firmware from the Keysight site.Attached here for convenience.It might be possible to glean something from inspecting the firmware file?Edit: I see now what was going on in the other thread, where it was unzipped... very nice! Do you think it is any more complicated than "filling" from the lowest address upwards? Maybe not all the chips are bad, if you get them out it might be possible to read the good ones and work out what is going on?

author: alexst
author_rank: Newbie
timestamp: June 19, 2020, 05:11:39 pm
content: Thanks for the reply and the firmware!The exe file from their website seems to contain a compressed image, however someone else on the forum here has managed to uncompress it:https://www.eevblog.com/forum/testgear/agilent-5462054640-series-unpacked-firmware-files/This is what a binwalk of it looks like:Code:MD5 Checksum: 5a4b99ff88c606b1f1353e2d7cba13b1Signatures: 391DECIMAL HEXADECIMAL DESCRIPTION--------------------------------------------------------------------------------477670 0x749E6 Certificate in DER format (x509 v3), header length: 4, sequence length: 8273806341 0xC4DC5 Neighborly text, "neighbor key region 0x%04x %2d"807534 0xC526E Neighborly text, "neighbor(0x%08x)= 0x%08x = %d"807788 0xC536C Neighborly text, "neighbor(0x%08x)= 0x%08x>key(0x%08x) = 0x%04x"1006565 0xF5BE5 LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 96 bytes1132424 0x114788 LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 48 bytes1350036 0x149994 Copyright string: "Copyright Agilent Technologies 1999"1350296 0x149A98 Copyright string: "Copyright Agilent Technologies 1999"1350842 0x149CBA Copyright string: "Copyright Agilent Technologies 1999"1351029 0x149D75 Copyright string: "Copyright Agilent Technologies 1999"1351212 0x149E2C Copyright string: "Copyright Agilent Technologies 1999"1351371 0x149ECB Copyright string: "Copyright Agilent Technologies 1999"1351522 0x149F62 TIFF image data, big-endian, offset of first image directory: 81351895 0x14A0D7 Copyright string: "Copyright Agilent Technologies 1999"1451414 0x162596 PARity archive data - file number 17408I'll see if I can find anything else that might be a clue.One possible explanation for having 4 chips is that two of them might be used as a scratch space during firmware updates?Edit: Oops, didn't see your editI hope they're filling them from the lowest address upwards - if so maybe it will be that simple! The TSOP48 socket will take a month or so to arrive.. I suppose this is getting shelved until then!

author: SilverSolder
author_rank: Super Contributor
timestamp: June 19, 2020, 05:51:16 pm
content: Quote from: alexst on June 19, 2020, 05:11:39 pmI see a lot of strings in there with my hex editor, including the entire Help text!What I can't find, are the file extensions .TXT or .CSV or .TIF which I know the scope uses when it outputs to floppy - Maybe this firmware file isn't the whole story? Does the amount of data in the file match the capacity of the chips?

author: alexst
author_rank: Newbie
timestamp: June 19, 2020, 07:18:14 pm
content: It doesn't really match - the chips are 1MB each, there's 4 of them and the firmware is 1.6M.grepping for file extensions is very clever though, thanks!I did find the following:Code:001429a0: 0015 cb19 0050 30c5 0200 0000 0050 3063 .....P0......P0c001429b0: 0052 9d00 2e54 4946 002e 5458 5400 2e47 .R...TIF..TXT..G001429c0: 4946 002e 424d 5000 2e43 5356 002e 5052 IF..BMP..CSV..PR001429d0: 4e00 2f00 2f44 4556 2f54 5459 002f 4445 N././DEV/TTY./DE001429e0: 562f 4345 4e54 002f 4445 562f 4750 4942 V/CENT./DEV/GPIB001429f0: 0000 0108 1611 0006 7bdc 0000 0000 0014 ........{.......It sounds plausible that it's the whole firmware, but the first few bytes are quite suspicious..Code:00000000: 0050 0000 0003 58ea 0000 0000 0000 0000 .P....X.........00000010: 6a45 6449 704c 7553 2020 2020 5241 4d3a jEdIpLuS RAM:00000020: 0002 0000 0018 ef04 0018 ef04 e861 d3cd .............a..00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................00000040: 202f 0004 2270 0fb0 0053 4658 2230 0fb0 /.."p...SFX"0..00000050: 0053 465c 4a89 6724 2009 5280 671e 4aa9 .SF\J.g$ .R.g.J.00000060: 0052 6718 2069 0052 2008 5280 670e 4aa8 .Rg. i.R .R.g.J.00000070: 0014 6708 2028 0014 5280 660e 23fc 0000 ..g. (..R.f.#...jEdIpLuS RAM?

author: SilverSolder
author_rank: Super Contributor
timestamp: June 19, 2020, 07:49:55 pm
content: Quote from: alexst on June 19, 2020, 07:18:14 pmLOL I see the jEdIpLuS too... Could just be a "magic string" used to recognize the file, so the firmware loader won't try to load an irrelevant file?I got fooled by my hex editor, it refused to find the "TIF" strings even though I did a case-insensitive search... it only does well with case sensitive searches... hadn't noticed that before. Worth the full price (free!)

author: kaldach79
author_rank: Contributor
timestamp: March 14, 2023, 01:41:00 pm
content: Hello,Have any of you managed to solve the firmware problem and fix it? I have exactly the same problem.Regards

author: SilverSolder
author_rank: Super Contributor
timestamp: March 28, 2023, 07:58:49 pm
content: Quote from: kaldach79 on March 14, 2023, 01:41:00 pmWhat problem are you talking about, specifically?