Dead Agilent 53220A

[jadew]

Hey guys,

I'm wondering if anyone knows if the processor boards, used in this device, can be troubleshooted or revived in any way. I have one of these counters and while power turns on when I press the button, nothing shows up on the screen. The FAN starts loud and then slows down, but no activity otherwise.

There is no activity on the serial bus either and if I plug in an ethernet cable, the device doesn't obtain an IP address.

All the voltages are fine on the motherboard and they seem fine on the processor board as well (even tho they're not labeled). I get the following values on the testpoints on the processor board: 1.8, 1, 1.2, 2.5 and GND.

Given that Keysight no longer wants users to repair their own equipment, and instead charge insane amounts for replacement assemblies, the service manual is a joke and no help at all. Judging by the behaviour, the voltages and the fact that nothing heats up, I'm thinking that maybe it has an issue with the flash or it could even be a firmware problem.

Any ideas on how to reflash that board? Should I try reflowing it?

Thanks

[HighVoltage]

May be the LAN service is turned off and that is the reason why you don't get an IP
Can you connect to the instrument over GPIB?

[jadew]

Doesn't have GPIB, but I don't get any output from the serial port either (the IDC-10 connector on the front panel).

[HighVoltage]

Did you buy it broken or do you know how it came to the fault?

Probably the only chance you have is finding a second good instrument and compare signals.

[jadew]

Bought it broken, so I have no way of knowing how it ended like this.

I've thought about buying a second unit, but a working one is a bit out of my budget for a counter. I'll probably end up doing that if nothing else works.

[HighVoltage]

Is this the one that was sold on ebay Germany about two weeks ago for Euro 250?
I was contemplating bidding but then something came up and I did not bid at all.

[TheSteve]

Great deal for a broken one - not as fun if it can't be fixed though.

Check the usual areas - all connectors/sockets and look for bad solder connections. Also pull the battery of course.

[jadew]

@HighVoltage, yeah, that's the one. At first it wasn't even turning on, but after some dicking around the power controller, the mother board decided to start, so this might have been as a result of a power failure. Spent already 3 days on it and this is the 4th, I'm starting to think it wasn't such a good deal.

@TheSteve, hopefully it can, I could really use a counter like this.

I checked all connectors and sockets and everything looks good. Already removed the battery, no luck there either.

[TheSteve]

When you say there is no activity on the serial bus are you referring to the one on the front panel? The WinCE image should have lots of information in the boot sequence.

[jadew]

@TheSteve, yeah, that one. I noticed there is some traffic between the main MCU and the flash next to it on power on, but not a lot of it and it stops fast.

[TheSteve]

Hmm, doesn't sound promising. What did you do to get it to power on as far it now gets?

[jadew]

I applied an offset on the ADC inputs of the power controller (it's PIC MCU). The one sensing the 15V line needed to see a bit more voltage than it had (just a bid). I inserted that in my tests with a resistor connected to a power supply, but eventually it started behaving properly without it.

I suspect it re-adjusts itself and stores those values in the EEPROM (which I managed to read and can confirm the values are different - doesn't work with the original ones), so, at least for the motherboard, it looks like a bug in the firmware.

The reason I started on this path was because as I was powering it from the lab supply (with the needed 15V), I noticed that if I don't make a good connection sometimes it starts by itself and I assumed that's because the levels it reads are varying enough that the power controller considers them fine.

[HighVoltage]

Are there any very hot parts to indicate that they are bad?
May be you can borrow a working second instrument?

[tec5c]

Doesn't have GPIB...

Are you sure? I find this hard to believe.

[DC1MC]

In the pdf here:

http://literature.cdn.keysight.com/litweb/pdf/53220-90010.pdf

in "Chapter 2  Service Troubleshooting the Counter" page 158 they give some voltages and what to do if something is not OK, did you try it, I don't see 3.3V on your list and 1.0V is rare, mostly FPGA stuff ?

 Good luck,
 DC1MC

[jadew]

Are there any very hot parts to indicate that they are bad?
May be you can borrow a working second instrument?

Nothing hot, everything appears to be normal. Checked it with thermal camera, also checked all caps, none is shorted.

Doesn't have GPIB...

Are you sure? I find this hard to believe.

On newer instruments they add GPIB as an option, you have to retrofit a board that provides this functionality.

In the pdf here:

http://literature.cdn.keysight.com/litweb/pdf/53220-90010.pdf

in "Chapter 2  Service Troubleshooting the Counter" page 158 they give some voltages and what to do if something is not OK, did you try it, I don't see 3.3V on your list and 1.0V is rare, mostly FPGA stuff ?

 Good luck,
 DC1MC

Yeah, all those are fine. The voltages I listed are for the processor board, because it has a couple of test points but none are labeled. The only things with labels there are the ICs.

I attached a photo of the board.

[TheSteve]

I believe some early units did not have GPIB but they have since made it standard equipment and should supply the upgrade free if you contact them.

With no serial debug info I am sure the processor card isn't booting at all, so you'll need to start there.

[DC1MC]

Nice picture of the CPU board, but the outlook doesn't look so good, I was suspecting that there is some FPGA involved and it is, it looks like the SMPS for the small voltages you've measured is working OK, and I believe the whole board is feed via 3V3 or 5V on pin 1 where the huge ferrite bead is, if it's anything else besides 3V3 I'd search for it on the board, because the ST MCU needs it for the I/O and most likely the FPGA too, if the 3V3 it's there OK, then there is no otter option:

It's HEADER TIME !!!

or else, due to BGA and hi-density packages

You can't touch this !!!

Joking aside, I bet that the 8pin header is the JTAG (most likely if you have Xlilinx programmer, you'll be able to read the chain) and that the bottom one has a lot other goodies, like serial debug for the CPU, voltages and interesting signals, so if push comes to show, populate them and start measuring.
Barring some other subtle power supply, connector or soldering issues, your only bet to repair the thing is to be a botched firmware update, and nowadays nobody bothers with dual firmware images and recovery partitions anymore, if it's dead you throw it away and replace it or fleabay it.    But it'll be a lot of pain to get a working firmware from somewhere.

 Now you really need Santa to bring you a box of luck, a most vital repair ingredient.



 

[jadew]

@DC1MC, the one on the top might be an alternate footprint for the IC below it, but I'll check it anyway.

I thought the same about the bottom connector, but the problem is that this board is facing up and it's placed under the main board, so when mounted, you can only see its back side. I don't know if I'll be able to fit the connector there. I can power it separately, just of the purpose of reading whatever is available to read, but my main concern is that I may not provide it with all the required voltages and end up frying some clamping diodes in the IOs.

I do have a Xilinx programmer and I was planning to try that, but I don't have a header that fits there at the moment. I'll have to order one, together with a resistor I destroyed on the mother board by mistake (soldered a wire to it and pealed off one of its contacts).

[DC1MC]

@DC1MC, the one on the top might be an alternate footprint for the IC below it, but I'll check it anyway.

I thought the same about the bottom connector, but the problem is that this board is facing up and it's placed under the main board, so when mounted, you can only see its back side. I don't know if I'll be able to fit the connector there. I can power it separately, just of the purpose of reading whatever is available to read, but my main concern is that I may not provide it with all the required voltages and end up frying some clamping diodes in the IOs.

I do have a Xilinx programmer and I was planning to try that, but I don't have a header that fits there at the moment. I'll have to order one, together with a resistor I destroyed on the mother board by mistake (soldered a wire to it and pealed off one of its contacts).

The  perfect solution is to have a raiser card, but I have a feeling that all the digital power is made for whatever voltage enters the pin 1 with its ginormous wide trace, it could be that for driving the LCD I/O it will be needed some other voltages, but I don't think that will explode if it doesn't have those. I'll only be concerned to not have some kind of locking signal on the connector, kind of POWER GOOD or RST.
I will put a logic analyzer and scope on the available pins of the eproms and ram, even if the CPU doesn't boot correctly you should see some activity.
It may be that there is some system wide reset or ready signal that holds the CPU in reset, and then you'll need to change the focus on the backplane signals.

It could be that the 8pin header it's for another model of I2C eeprom, it's easy to check it against the chip under it. If it was an update failure or a flash content gone wrong, you may have the chance that the CPU drops in a  kind of bootloader with a serial console, if you're stinky lucky, even uboot.
Because I think that your main concern it's now to boot the CPU, other stuff, once the CPU is OK, could be done with the board in place.

 Cheers,
 DC1MC

[jadew]

I'll only be concerned to not have some kind of locking signal on the connector, kind of POWER GOOD or RST.

This thought crossed my mind too and investigated the possibility, because the power LED wasn't turning amber when power was applied on the back (I thought it should). Later I found out that it turns amber only if it has the OCXO installed, so what I was observing was correct behaviour. Given that all power lines are turned on and stay on, indicates that it reads correct voltages, so if there's such a signal, I assume it would be asserted too.

If there is such a signal and it's not being asserted, it's going to be difficult to figure out which one it is.