Agilent/HP E3646A Repair - Page 1
Forum section: electronics / repair

author: ddcc
author_rank: Regular Contributor
timestamp: March 04, 2017, 10:51:09 pm
content: I picked up a broken Agilent/HP E3646A power supply recently, but haven't been able to figure out where the problem is. When I turn it on, the unit beeps twice, and then the display goes blank. According to the manual/schematics, this corresponds to error 601, that U1 (Microchip HV518PJ) on the display board cannot communicate with U17 (Intel N80C196KB16) on the controller board (see schematic pgs. 216, 218). From my reading of the schematic, this could be caused by power failures on the 5V, -12.4V, and -17.4V supply rails, or component failures of the microcontroller U7 (Intel N80C51BH), comparator U8 (LM339M), shift register U6 (74HC299D), D flip-flop U5 (74HCT74D), or NOR gate U4 (74HC02) on the display board, or U16 (National SCX6206AK0) on the control board. Since the buzzer is triggered by microcontroller U7 (Intel N83C51FA) on the control board, this could also include the schmitt trigger U4 (HCT14A), or optoisolator U9 (HCPL-2211).For reference, here are the relevant pages of the schematic:https://drive.google.com/uc?export=view&id=0B0VVuuoZ-KQeX1lnOGNsOVZ1akE, and to the entire Google Drive folder :https://drive.google.com/drive/folders/0B0VVuuoZ-KQea0N1Y2k3T3RtV2c?usp=sharing. Here's what I've done so far:Starting off, I measured the three supply rails, which all look fine. On the control board, I probed U16, U17 with a logic analyzer, which shows bidirectional communication going out from the control board on FPDI, and coming back on FPDO. U16 seems to be communicating with U17 on RXD, which I'm guessing is running at 12 MHz / 64 = 187500 baud, and U17 seems to be communicating with U9 on IGTXD. Note that some of the captures are analog, because the digital logic levels are inside the undefined region between logic low (0.6V) and high (1.2V) or outside the defined region of the Saleae Logic 8.By U9, I can see IGTXD coming in and going through to U4, then on to U7, which triggers the buzzer.Moving on to the display board, I can see these signals are shifted by U8 to the -12.4V to -17.4V range, suggesting that they are reach U7 fine. On the output side from U7, the shift register U6 looks normal, as does the delay D flip-flop U5.Over by the VFD driver, the clock is inverted by U4, the signal is delayed by the D flip-flop U5, and then enters the VFD driver U1, which all looks fine.Since there's no output from U1, my understanding is that essentially U7 needs to communicate with U16, which then talks to U17 and triggers the buzzer. But all of this looks fine, which is why I'm stumped. Any suggestions?

author: Shock
author_rank: Super Contributor
timestamp: March 05, 2017, 02:06:00 am
content: Has the display been turned off via a remote interface system command? Just saying because it's happened several times here before.

author: ddcc
author_rank: Regular Contributor
timestamp: March 05, 2017, 03:35:08 am
content: I don't know the full history of the unit, but I don't believe so. The unit always beeps twice at startup, and I can't trigger the full self-test from the display, so I'm inclined to think that it's an error condition.But now that you mention it, I'm curious to see if I can communicate with the unit over RS-232, though I'll need to pick up a USB to RS-232 converter.

author: vtp
author_rank: Regular Contributor
timestamp: March 05, 2017, 12:00:10 pm
content: MCU on the display board faulty?I had one similar where everything looked just fine but main board 80C196 was not able to communicate with front panel 80C51. In that case (and in many others later) the front panel MCU was the problem.This case looks very similar to mine in that the 80C51 I/O pins supposedly receives 0x00 as in your pictures but the whole thing still does not work. I do not remember what the front panel MCU was supposed to answer with but if you can figure that out then you can check the communication properly....Two common reasons for broken FP MCU is broken rotary encoder or misaligned keypad.In both cases analog ground from which the +5V operating voltage is derived using -17.4V as ground reference can short to MCU I/O pin. This means zapping MCU pin with +17.4V.Encoder the case is conneced to AGND. If the encoder breaks there is a very good change the encoder case will short AGND and MCU I/O reading the encoder and kill the MCU.In keypad there is opening on solder mask surrounding every key and if the keypad is misaligned the MCU is killed with one keypress by shorting the keyboard AGND static shield to MCU keypad I/O pin.

author: ddcc
author_rank: Regular Contributor
timestamp: March 05, 2017, 08:42:43 pm
content: I had the same suspicion originally, especially since the previous owner mentioned accidentally shorting the zeners on the +/-17.4V bias supply. So I desoldered U7 (N80C51BH), dumped the firmware, installed a PLCC44 socket, flashed an AT89S51, and installed it instead. I haven't worked with 8051's before, but the two appeared instruction set and pin compatible, so it seemed to be a valid substitute. But when I probe the communication between the display and control board, everything remains the same, regardless of whether I'm using the AT89 or the original 8051. As a control, I tried this once without anything installed in the PLCC44 socket, and the FPDO line was entirely low, as expected. I just checked the encoder, but both outputs are pretty much in the -12.4 to -17.4V range, so it seems fine.Previously, I also replaced both U8 (LM339) and U6 (HC299), before I realized that some of my bizarre digital logic captures were being caused by the logic level thresholds on the Saleae. So this almost leads me to suspect now that the issue could be with the FPDO input on U16 (SCX6206), except that would be really unfortunate because I can't replace the part. The only other thing that I can think of is that I've been doing all my testing with the VFD removed, but I don't think that should be affecting anything.

author: vtp
author_rank: Regular Contributor
timestamp: March 05, 2017, 09:14:20 pm
content: VFD removed is no problem, it should work nevertheless. Of course you can't see what is happening but one short beep on turn on would tell that the FP comms is ok.Just today some hours ago I did the same as you did with FP MCU. I have had this E3634A as a project for months now on and off and just finished repairing it. I took off the FP MCU, put in a socket and reprogrammed a new MCU. Old MCU measured 8 ohms between VDD and GND and was most likely a casualty of a broken rotary encoder.What happened while removing the old MCU and soldering in a socket was that one pad became loose. When soldering in the socket the trace from the pad cracked. And of course everything looked good under microscope as the crack was under the socket. Only continuity test from the socket to other parts of the circuit revealed the problem. What made this even more difficult was that the pin in question was #16, that is FPSCK. It looks like the MCU does not do anything (no pin whatsoever wiggling) when it is waiting for communication - and nothing was happening as it was not getting serial clock.My lesson learned was that always check the signals from pin to pin and do not trust measurements in between. I am not sure if you have measured all the way to the SCX6202 FPDO, I would assume you have as you mention it. That gate array btw is used in many similar age HP instruments like 34401A. There can be parts units available.Your FP MCU seem to have revision 1 firmware, can you drop that to some repository like ko4bb where also v2 is stored? V2 appears to be drop in compatible, at least in my E3634A case.

author: ddcc
author_rank: Regular Contributor
timestamp: March 05, 2017, 10:41:05 pm
content: Hmm, good to keep in mind. Yeah, I've probed the SCX6206 directly at the FPDO pin, that's why I have it propped up in that photo to get access to the pins on the far right side. Do you know what the N80C51BH is supposed to send back? All of my captures have shown that it replies to '0x00' with '0x77', as seen in the first photo of the original post.Is the SCX6206 actually replaceable though? The datasheet says that the user's design is imposed onto the wafer, implying a mask program is etched at the factory? From looking online at photos of 34401A (e.g.https://doc.xdevs.com/doc/HP_Agilent_Keysight/photo/34401A/), I'm not seeing the SCX6206 on the board. I'm really hesitant to go down the rabbit hole of buying donor units to repair this unit, mainly because it's expensive and there's no guarantee the donor will be compatible.I'm not familiar with the KO4BB repository, could you be more specific? I don't see any E364X-related firmware athttp://www.ko4bb.com/getsimple/index.php?id=manuals&dir=HP_Agilent.

author: vtp
author_rank: Regular Contributor
timestamp: March 06, 2017, 07:11:22 am
content: Quote from: ddcc on March 05, 2017, 10:41:05 pmIt's a gate array. HP part number is 1820-8907, IC-SCX6206AK0. The suffix AK0 means mask set applied and seem to be used in many HP instruments of that era. Check the bill of materials for the same part number.Quote from: ddcc on March 05, 2017, 10:41:05 pmI meant the FP MCU firmware. You can find it there searching for 34401A.

author: ddcc
author_rank: Regular Contributor
timestamp: March 06, 2017, 09:56:51 pm
content: I've uploaded it, and found the newer 34401-88813 version you mentioned.Thanks for the part number, that seems more accurate than SCX6206, which is omitted on the 34401A photos. From a quick search, 1820-8907 seems to be used on the 33120A, 34401A, E1412A, E3632A, E3633A, and E3634, of which the 34401A is easiest to find online. Guess I'll have to wait around and hope someone lists a broken board/unit for cheap.I'll try the 34401-88813 later and see if it makes a difference. Otherwise, would you agree that replacing the SCX6206 is the next step? Or is there something else I'm missing?

author: ddcc
author_rank: Regular Contributor
timestamp: March 07, 2017, 03:57:39 am
content: Just tried the 34401-88813, and the double beeps still continue. But, I'm more confident that the problem isn't on the display board, because I disassembled the 34401-88813 display board firmware, looked at the other possible values that are sent (0xA5, 0x77, 0xBB, 0xDD), patched the firmware at 0x374 to try sending each of them, verified that they are sent with the logic analyzer, and have still observed no change. The two firmware are almost identical, except for a few small changes, so I went with the new one. Looks like I'll need to keep my eye out for a 1820-8907.For reference, this is the function that is setting the SPI reply, which is called by the reset routine at startup:Code:code:0000036C ; =============== S U B R O U T I N E =======================================code:0000036Ccode:0000036Ccode:0000036C code_36C: ; CODE XREF: RESET_0+A0pcode:0000036C ; code_800+15p ...code:0000036C jb RAM_21.4, code_387 ; Jump if Bit is setcode:0000036F jb RAM_21.3, code_387 ; Jump if Bit is setcode:00000372 mov RAM_58, A ; Move (Op1 <- Op2)code:00000374 mov RAM_5A, #0x77 ; 'w' ; FPDOcode:00000377 jnb RAM_22.4, code_381 ; Jump if Bit is clearcode:0000037A mov RAM_5A, #0xA5 ; ' ; FPDOcode:0000037D setb RAM_22.6 ; Set Direct Bitcode:0000037F clr RAM_22.4 ; Clear Operand (0)code:00000381code:00000381 code_381: ; CODE XREF: code_36C+Bjcode:00000381 setb RAM_21.3 ; Set Direct Bitcode:00000383 mov RAM_1A, #1 ; Move (Op1 <- Op2)code:00000386 ret ; Return from subroutinecode:00000387 ; ---------------------------------------------------------------------------code:00000387code:00000387 code_387: ; CODE XREF: code_36Cjcode:00000387 ; code_36C+3jcode:00000387 mov RAM_55, A ; Move (Op1 <- Op2)code:00000389 setb RAM_22.5 ; Set Direct Bitcode:0000038Bcode:0000038B code_38B: ; CODE XREF: code_39D+32jcode:0000038B jbc RAM_22.4, code_390 ; Jump if Bit is set & clear Bitcode:0000038Ecode:0000038E code_38E: ; CODE XREF: code_39D+20jcode:0000038E clr RAM_22.5 ; Clear Operand (0)code:00000390code:00000390 code_390: ; CODE XREF: code_36C:code_38Bjcode:00000390 setb RAM_21.2 ; Set Direct Bitcode:00000392 ret ; Return from subroutinecode:00000392 ; End of function code_36CNote that bits 0 - 5 of RAM_21 and bits 1, 2, and 4 of RAM_22 are cleared earlier in RESET_0 before this function is called, so none of the branches at 0x36C and 0x36F are taken, whereas 0x377 is taken. But, RAM_21.3 is set at 0x381 before the function returns. The caller routine, RESET_0, is called by the reset vector, but also contains the main event loop for the microcontroller that never terminates. Right before it restarts the loop, it calls another function, which sends the SPI reply:Code:code:00000273 ; =============== S U B R O U T I N E =======================================code:00000273code:00000273code:00000273 code_273: ; CODE XREF: RESET_0:code_23Epcode:00000273 push PSW ; Program Status Word Registercode:00000275 mov PSW, #0x18 ; Program Status Word Registercode:00000278 jb RAM_21.5, code_2D7 ; Jump if Bit is setcode:0000027B jb RAM_21.4, code_2AC ; Jump if Bit is setcode:0000027E jb RAM_21.3, code_2AC ; Jump if Bit is setcode:00000281 jbc RAM_21.2, code_298 ; Jump if Bit is set & clear Bitcode:00000284 jb INT1, code_291 ; Port 3code:00000287 setb T1 ; Port 3code:00000289 mov P2, #0xFF ; Port 2code:0000028C setb T0 ; Port 3code:0000028E pop PSW ; Program Status Word Registercode:00000290 ret ; Return from subroutinecode:00000291 ; ---------------------------------------------------------------------------code:00000291code:00000291 code_291: ; CODE XREF: code_273+11jcode:00000291 jb RAM_21.3, code_2AC ; Jump if Bit is setcode:00000294 setb RAM_21.4 ; Set Direct Bitcode:00000296 sjmp code_2AC ; Short jumpcode:00000298 ; ---------------------------------------------------------------------------code:00000298code:00000298 code_298: ; CODE XREF: code_273+Ejcode:00000298 setb RAM_21.3 ; Set Direct Bitcode:0000029A mov RAM_58, RAM_55 ; Move (Op1 <- Op2)code:0000029D mov RAM_5A, #0x77 ; 'w' ; FPDOcode:000002A0 jnb RAM_22.5, code_2AA ; Jump if Bit is clearcode:000002A3 mov RAM_5A, #0xA5 ; ' ; FPDOcode:000002A6 setb RAM_22.6 ; Set Direct Bitcode:000002A8 clr RAM_22.5 ; Clear Operand (0)code:000002AAcode:000002AA code_2AA: ; CODE XREF: code_273+2Djcode:000002AA mov R2, #1 ; Move (Op1 <- Op2)code:000002ACcode:000002AC code_2AC: ; CODE XREF: code_273+8jcode:000002AC ; code_273+Bj ...code:000002AC setb T1 ; Port 3code:000002AE mov P2, #0x7F ; '' ; Port 2code:000002B1 clr T0 ; Port 3code:000002B3 setb T0 ; Port 3code:000002B5 mov P2, #0xFF ; Port 2code:000002B8 clr T1 ; Port 3code:000002BA clr EA ; Interrupt Enable Registercode:000002BC clr T0 ; Port 3code:000002BE setb T0 ; Port 3code:000002C0 setb T1 ; Port 3code:000002C2 mov P2, RAM_5A ; FPDOcode:000002C5 clr T0 ; Port 3code:000002C7 setb T0 ; Port 3code:000002C9 clr T1 ; Port 3code:000002CB setb TR0 ; Timer 0/1 Control Registercode:000002CD mov P2, #0xFF ; Port 2code:000002D0 setb RAM_21.5 ; Set Direct Bitcode:000002D2 setb EA ; Interrupt Enable Registercode:000002D4 pop PSW ; Program Status Word Registercode:000002D6 ret ; Return from subroutinecode:000002D7 ; ---------------------------------------------------------------------------code:000002D7code:000002D7 code_2D7: ; CODE XREF: code_273+5jcode:000002D7 mov A, TL0 ; Timer 0, Low Bytecode:000002D9 anl A, #0xF8 ; Logical AND (op1 &= op2)code:000002DB jz code_2EE ; Jump if Acc is zerocode:000002DD clr TR0 ; Timer 0/1 Control Registercode:000002DF mov TL0, #0 ; Timer 0, Low Bytecode:000002E2 mov R3, P2 ; Port 2code:000002E4 setb T1 ; Port 3code:000002E6 clr RAM_21.5 ; Clear Operand (0)code:000002E8 mov DPTR, #0x2F1 ; Move (Op1 <- Op2)code:000002EB mov A, R2 ; Move (Op1 <- Op2)code:000002EC rl A ; Rotate Acc leftcode:000002ED jmp @A+DPTR ; Jump indirect relative to Data Pointercode:000002EE ; ---------------------------------------------------------------------------code:000002EEcode:000002EE code_2EE: ; CODE XREF: code_273+68jcode:000002EE pop PSW ; Program Status Word Registercode:000002F0 ret ; Return from subroutinecode:000002F0 ; End of function code_273On reset, the branches at 0x278 and 0x27B are not taken since those bits RAM_21.5 and RAM_21.4 are still (presumably) cleared, but since RAM_21.3 is now set, the branch at 0x27E is taken to 0x2AC, which skips over the block at 0x298 that would otherwise set the SPI reply to 0xA5/0x77, and writes out the contents of RAM_5A to port 2 at 0x2C2.

author: vtp
author_rank: Regular Contributor
timestamp: March 07, 2017, 07:27:42 am
content: You could check the SCX6206 I/O-pin used for front panel signaling by separating it from the rest of the circuitry and checking if you can find latch-up protection diodes from the pin to VDD and GND. If they are not there, there is a good chance bonding wire is loose.I think each front panel serial line has series resistors on the main board so it should be easy to separate those pins. XCS6206 datasheet is also available somewhere in the net (datasheetarchive?) but I can't recall if it had I/O-pin specifications.

author: ddcc
author_rank: Regular Contributor
timestamp: March 09, 2017, 02:01:04 am
content: I lifted pin 6 (FPDO) on the SCX6206 QFP package, and the bond wire seems fine. Treating the pin as positive, I see 0.55M(1.17V in diode mode) to ground, 0.54M(1.17V in diode mode) to VCC, and in reverse, 490k(0.82V) to ground, and 489k(1.32V in diode mode) to VCC. There's no block diagram on the schematic, but the datasheet states "all inputs and I/Os protected from over-voltage and latch-up", so I'm assuming that there are diodes from GND and to VCC.

author: ddcc
author_rank: Regular Contributor
timestamp: April 04, 2017, 06:30:44 am
content: I bought a replacement SCX6206AK0/V4 from a chinese parts broker (Utsource), desoldered the old one, and replaced it with the new one. Now, it only beeps once at startup, instead of twice, which is the expected behavior. Since this was with the old N80C51BH on the display board socket, I left it in, and soldered back on the VFD. Unfortunately, the display lights up briefly at startup, but then goes dim, and doesn't seem to respond to any input. In hindsight, I should have put in the AT89S51, because now I need to desolder the VFD again to get to it... oops! I'm really starting to think about buying a rework station with a vacuum pump, because I'm getting tired of desoldering with a cheap hand pump and solder wick. I used to have access to a Pace MBT350 in a university lab, but that's way outside of my budget.

author: ddcc
author_rank: Regular Contributor
timestamp: April 08, 2017, 09:57:51 pm
content: I tried switching out the N80C51BH with the AT89S51, but that didn't change the issue with the display. Probing U1 (HV518PJ), I see data going in, but nothing going out to the anodes, so I suspect that the shift register or latch component in this chip is dead. But, the output is fine, because when the strobe signal is high (e.g. at startup), it does turn on all of the segments. So now I'll need to order the replacement.Unfortunately, when desoldering the VFD again, I accidentally broke off two of the pins right at the edge of the glass, though there does seem to be enough of a stub left that I can solder up wires. I'd like to replace the VFD (SVI-12MS06), since the display is also quite dim, but it seems like a custom part that's hard to find.

author: ddcc
author_rank: Regular Contributor
timestamp: October 06, 2017, 05:59:03 am
content: Wow, it's been a while since I last updated this post. I managed to order a replacement VFD, and reassembled the display board. Using a known good E3648A, I've verified that fault is somewhere on the control board on the E3646A; if I swap in the control board from the E3648A, then everything works perfectly. But, the current symptom is still a single medium-length beep at startup, and no output on the display.I'm fairly confident that the fault is somewhere around U17 (N80C196KB16) or U16 (SCX6206AK0), but despite putting in PLCC-68 sockets and swapping out those two parts, nothing has changed. Just in case, I've also swapped out the SRAM, U11 (NEC uPD43256BGU-70LL), with an ISSI IS62C256AL-45ULI, but that also hasn't made a difference. I checked the optoisolators U9 and U10; U10 is definitely good, because I can see data pulses from U7 being transmitted across it. I'm not sure about U9, but the output from U17 into the optoisolator isn't right; there's a weird constant 3.7V +/- 0.1Vpp ripple on IG_TXD instead of the signal I see on the E3648A control board, which makes me suspect either the U12 EPROM, the replacement U17, or the replacement U11 SRAM, since the chip doesn't even appear to boot.Does anyone have a dump of the U12 "E3646-60023 Rev 1.4" EPROM by any chance? The version on the E3648A is labeled "E3646-60023 Rev 1.7", so I'm not sure if it's compatible. I have a few AT27C020-55JU, which appear to be compatible OTP EPROMs for U12. At the moment, my inclination is to try another U17, and find an original U11 SRAM instead of the ISSI part.

author: Ordinaryman1971
author_rank: Frequent Contributor
timestamp: December 09, 2017, 06:58:22 pm
content: I have six of those power supppies if you want to borrow one for comparison let me know. Maybe stare and compare is a way to do it.

author: ddcc
author_rank: Regular Contributor
timestamp: December 09, 2017, 10:18:00 pm
content: Quote from: Ordinaryman1971 on December 09, 2017, 06:58:22 pmThanks for the offer! I was able to fix the power supply, so no need.Turns out there was an issue in the separate bias supply on the control board, followed by some problems with the ADC circuit and a bad overvoltage protection supervisor, but I replaced all of the bad components.

author: cnqhdszq
author_rank: Regular Contributor
timestamp: December 10, 2017, 02:44:25 pm
content: had been repaired off ??

author: ddcc
author_rank: Regular Contributor
timestamp: December 10, 2017, 10:09:11 pm
content: Quote from: cnqhdszq on December 10, 2017, 02:44:25 pmSorry, I don't understand.

author: Ordinaryman1971
author_rank: Frequent Contributor
timestamp: December 14, 2017, 04:51:49 pm
content: Would you be willing to list the components you've found faulty.One of mine developed the same problem few days ago. When I turn it on, the display comes to life but goes dead right after.I've swapped control board from the other unit and the display as well as the power supply are fine.So, the fault is on the control board. It looks like the same trouble you had.

author: ddcc
author_rank: Regular Contributor
timestamp: December 14, 2017, 06:09:44 pm
content: Quote from: Ordinaryman1971 on December 14, 2017, 04:51:49 pmWhen you say it comes to life, is it all the segments that light up? And then you never see "Output Off", or does it show up and go away? Do you get any beeps? Two beeps is a problem communicating between U16/U17 and the display board. For me, one beep was caused by a problem with the bias voltages on the control board, so check the -17.4/+17.4 rails, the -15/+15 bias rails (around CR8, CR9), the 5V regulators (U5, U14), and the -5V bias rail (CR15). In addition to being faulty, my CR8 was slightly discoloured with a small burn mark on the black plastic.

author: Ordinaryman1971
author_rank: Frequent Contributor
timestamp: January 11, 2018, 06:34:15 pm
content: Thanks for tips, let me see what I can find out. In my case there was one beep and the screen was completely off... no signs of life.Let me measure the rails and get back with you.

author: analogRF
author_rank: Super Contributor
timestamp: August 29, 2018, 01:07:23 pm
content: Quote from: ddcc on April 04, 2017, 06:30:44 amHiDo you mean replacing SCX6206AKO does not need any kind of programming? Just drop in a replacement part and that's it? I might need to replace it on my E3631A and utsource still has it.

author: ddcc
author_rank: Regular Contributor
timestamp: August 29, 2018, 03:14:57 pm
content: Quote from: vtp on March 06, 2017, 07:11:22 amYeah, it's pre-programmed with the mask ROM. Though I've only seen older equipment use the SCX6206AK0 part number, newer ones seem to have various different part numbers printed on the gate array.

author: SoundTech-LG
author_rank: Frequent Contributor
timestamp: August 29, 2018, 08:58:32 pm
content: All the working normally E3631A supplies in this lab (all 7 of them) beep twice on turn on.Seems like there might be some confusion on this, because the manual seems to indicate an error if there are beeps. Swapping out the VFD is a bear, but patience, and solder wick work pretty well. It started as a rotary encoder replacement, but the VFD vacuum seal is right nearby and breaks off easily...I got another one from Top Dog Test on the bay for $60