Agilent 54622D not booting - CPU keeps getting reset

[alexst]

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!

[SilverSolder]

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.

[giovannirat]

Try to check the DTACK signal. It could be a memory problem, in that case IMHO a watchdog timer kicks in......

[alexst]

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?

[alexst]

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 to https://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!

[SilverSolder]

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?

[alexst]

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: [Select]

MD5 Checksum:  5a4b99ff88c606b1f1353e2d7cba13b1
Signatures:    391

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
477670        0x749E6         Certificate in DER format (x509 v3), header length: 4, sequence length: 8273
806341        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 bytes
1132424       0x114788        LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 48 bytes
1350036       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: 8
1351895       0x14A0D7        Copyright string: "Copyright Agilent Technologies 1999"
1451414       0x162596        PARity archive data - file number 17408

I'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 edit
I 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!

[SilverSolder]

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: [Select]

MD5 Checksum:  5a4b99ff88c606b1f1353e2d7cba13b1
Signatures:    391

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
477670        0x749E6         Certificate in DER format (x509 v3), header length: 4, sequence length: 8273
806341        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 bytes
1132424       0x114788        LZMA compressed data, properties: 0xC0, dictionary size: 0 bytes, uncompressed size: 48 bytes
1350036       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: 8
1351895       0x14A0D7        Copyright string: "Copyright Agilent Technologies 1999"
1451414       0x162596        PARity archive data - file number 17408

I'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 edit
I 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!

I 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?

[alexst]

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: [Select]

001429a0: 0015 cb19 0050 30c5 0200 0000 0050 3063  .....P0......P0c
001429b0: 0052 9d00 2e54 4946 002e 5458 5400 2e47  .R...TIF..TXT..G
001429c0: 4946 002e 424d 5000 2e43 5356 002e 5052  IF..BMP..CSV..PR
001429d0: 4e00 2f00 2f44 4556 2f54 5459 002f 4445  N././DEV/TTY./DE
001429e0: 562f 4345 4e54 002f 4445 562f 4750 4942  V/CENT./DEV/GPIB
001429f0: 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: [Select]

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?

[SilverSolder]

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: [Select]

001429a0: 0015 cb19 0050 30c5 0200 0000 0050 3063  .....P0......P0c
001429b0: 0052 9d00 2e54 4946 002e 5458 5400 2e47  .R...TIF..TXT..G
001429c0: 4946 002e 424d 5000 2e43 5356 002e 5052  IF..BMP..CSV..PR
001429d0: 4e00 2f00 2f44 4556 2f54 5459 002f 4445  N././DEV/TTY./DE
001429e0: 562f 4345 4e54 002f 4445 562f 4750 4942  V/CENT./DEV/GPIB
001429f0: 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: [Select]

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?

LOL 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!)

[kaldach79]

Hello,
Have any of you managed to solve the firmware problem and fix it? I have exactly the same problem.
Regards

[SilverSolder]

Hello,
Have any of you managed to solve the firmware problem and fix it? I have exactly the same problem.
Regards

What problem are you talking about, specifically?