EEVblog Electronics Community Forum
Electronics => Repair => Topic started by: EHT on February 20, 2022, 11:04:29 pm
-
I'd appreciate views on this annoying fault I have with a programmable power supply. Overall a very complex beast to which the interweb will not yield a schematic. Sorensen XG series - user manuals here (https://www.programmablepower.com/products/dc-power-supplies/xg-850). It has digital control and USB/RS-485 interfaces. The general design is fairly clear and it can be seen in this video (https://www.youtube.com/watch?v=OMRwFnNHmk8).
Initially, the TOP224YN switching regulator IC which provides power for the internal circuits was intermittently faulty. I’ve replaced this, and the internal supplies are now good. However, although the unit is showing many signs of life, it is a Zombie!
a) The front panel display is dead and controls inoperative
b) The OVP protection (?) MOSFET is sinking some current
At least the behaviour is not intermittent, but I’m not so sure which route to take debugging this now. I had been focusing my attention on why the OVP MOSFET is conducting, but having gone through that circuit extensively I’m not sure the fault is there (I can post more details of the circuit). I’m wondering if its more useful to look into the microcontroller and digital circuits. Any view on this, or how to proceed debugging the digital side would be appreciated.
I have checked all supply rails, used diode-test where possible and tried to look for physical damage or heat dissipation. The unit has suffered some abuse as it had dirt and moisture blown in through the fans. There was some corrosion visible on bolts across the whole PCB and on metal part of transistors etc. However, the visible damage was not too much after cleaning. It seemed like it had been operating somewhere damp from the pattern left by the air flow.
Here are my observations:
Observed Behaviour:
• Fans come on immediately, but front panel display and LEDs blank. Controls have no effect. The LED displays should show 8888-8888 at startup.
• After a couple of seconds the inrush relay can be heard and 14.00V is present at the main output
• Checking the rear analog programming ports, the voltage monitor readback is 4.2482v, which scales to 14.1v if 10.0v readback = 100% of 33v (max o/p). The status pin (J2_13) goes high indicating there is apparently not a fault condition.
• There is one MOSFET, Q25 2SK2837 which is placed across the main rails, I guess for OVP. This is heating up noticeably, sinking about 3-4W. I haven’t left it on for a long time, but it fairly quickly reaches 40-50C.
Circuit description and detailed observation:
Here is a description of the main sections and what I observe in each:
1) mains filter with inrush protection relay
• relay comes on after a few seconds as normal
2) PFC controller based on L4981AD (https://www.st.com/resource/en/datasheet/l4981.pdf (https://www.st.com/resource/en/datasheet/l4981.pdf))
• replaced a corroded cap which would prevent it oscillating, now probably OK. Output is about 390V DC
3) Main PSU Switcher based on M51995AFP(https://pdf1.alldatasheet.com/datasheet-pdf/view/115167/RENESAS/M51995AFP.html (https://pdf1.alldatasheet.com/datasheet-pdf/view/115167/RENESAS/M51995AFP.html)
• Havent checked this circuit, but we do have stable output voltage from the main PSU output
4) Internal Supply using a TOP224YN (https://www.farnell.com/datasheets/2059937.pdf (https://www.farnell.com/datasheets/2059937.pdf)) switcher. This has multiple outputs, all of which are good now:
• a main +5V supply from an LM2940 which seems to supply the main logic circuits and front panel
• +/- 15V from 7*L15 8-pin ICs for the Op-Amps (LM324, OP2177) – good
• +18v VCC to the L4981AD and M51995AFP – good
• Feeds to other isolated supplies for USB, RS232 etc. – not checked
5) Logic section with a microcontroller (not sure what type, as it has version sticker on it. See pic. Update - I think 80C51 variant, given location of VCC, GND pins), provided RS232, RS485, USB. Socketed PLCC44 pin design with 22.1184 MHz clock.
• VCC and clock signal present.
• Some other signals can be seen, but I don’t know what I’m looking at…
• Has a MAX1232 watchdog – this is giving initial reset pulse as expected.
• Tried USB with FTDI driver. Windows recognises the USB port being plugged in but I can’t open a connection with Putty.
6) Front panel with I2C PCA9555 GPIO (https://www.nxp.com/docs/en/data-sheet/PCA9555.pdf (https://www.nxp.com/docs/en/data-sheet/PCA9555.pdf)) and MC14489 display drivers. Power for this board comes from the main +5v.
7) ADC https://www.analog.com/media/en/technical-documentation/data-sheets/AD7708_7718.pdf (https://www.analog.com/media/en/technical-documentation/data-sheets/AD7708_7718.pdf)) and multiple MAX5441 DACs, MAX6225 v ref.
Between these sections there are about 30 (!) opto couplers, mostly NEC 2561 type(https://www.farnell.com/datasheets/89573.pdf. (https://www.farnell.com/datasheets/89573.pdf.) I’ve checked the diodes but not done the harder check of transistor on-resistance.
-
OK, the microcontroller is an 80C51 variant running at 22MHz. I see these signals on the pins when running. I haven't looked closely to see if there is further activity at the startup but it certainly looks to have crashed.
Could anyone suggest if this relative lack of activity means the MCU is definitely dead?
Pin Function Measurement (High = +5v, Low = 0v)
1 n/c High
2 P1.0 / T2 High
3 P1.1/T2EX Pulses, mainly high
4 P1.2/ECI Pulses, mainly high
5 P1.3/CEX0 Slow oscillation, 1Hz
6 P1.4/CEX1 High
7 P1.5/CEX2 High
8 P1.6/CEX3 High
9 P1.7/CEX4 High
10 RST Low (good - no reset. Pulse is generated on startup)
11 P3.0 / RxD High
12 n/c Low
13 P3.1/TxD High
14 P3.2/INT0 Low
15 P3.3/INT1 Low
16 P3.4/T0 High
17 P3.5/T1 1.72v (suspect)
18 P3.6/WR 1.1v (suspect)
19 P3.7/RD Pulses, 100ns, then high
20 xtal2 22Mhz
21 xtal1 22Mhz
22 VSS Low
23 n/c High
24 A8 High
25 A9 High
26 A10 High
27 A11 High
28 A12 Pulses, normally high
29 A13 Slow oscillation, 1Hz
30 A14 High
31 A15 Slow oscillation, 1Hz
32 PSEN High
33 ALE/PRG Burst of pulses, 3MHz
34 n/c High
35 EA High
36 AD7 Slow oscillation, 1Hz
37 AD6 High
38 AD5 Slow oscillation, 1Hz
39 AD4 High
40 AD3 0.14v (suspect)
41 AD2 High
42 AD1 High
43 AD0 High
44 VCC High
-
Burst of ALE indicates that it's trying something.
From 1Hz my guess is that something internal is pulsing it.
I'd start from that AD3.
Since ALE is used Data should also be used.
Are there data and address pairs, like A15-AD7 and A13-AD5.
Then A11-AD3 is missing and instead there's A12.
-
Thanks very much for the pointers! I'll continue looking. One simple thing might be corrosion on the MCU socket and PLCC pins - there was definitely moisture in the unit. However, I can't see any and this area of the PCB was quite clean. I sprayed some IPA on it and nudged it, but have a proper PLCC extractor tool on its way so i can remove and clean it.
I'll try tracing back where the A and AD lines route to. All of the digital chips I can find are serial: MAX5541 DACs, AD5263 'digital pots', AD77188 ADC and PCA9555 GPIOs, all serial. I'm not sure what AD0-7 will be used for. There is no external memory.
Another thing I could look for is testing some of these lines from power on to see if they are operational at some point. Once I remove the MCU I could also check the resistance measures the same on each similar pin.
Are there data and address pairs, like A15-AD7 and A13-AD5.
Then A11-AD3 is missing and instead there's A12.
I didn't quite follow what you meant by the pairs?
-
googled
Mnemonic Pin Number
DIL PLCC44 VQFP44 1.4 Type Name and Function
VSS 20 22 16 I Ground: 0V reference
VCC 40 44 38 I Power Supply: This is the power supply voltage for normal, idle and power-down operation
P0.0 - P0.7 39 - 32 43 - 36 37 - 30 I/O Port 0: Port 0 is an open-drain, bi-directional I/O port. Port 0 pins that have 1s
written to them float and can be used as high impedance inputs. Port 0 must be
polarized to VCC or VSS in order to prevent any parasitic current consumption. Port
0 is also the multiplexed low-order address and data bus during access to external
program and data memory. In this application, it uses strong internal pull-up when
emitting 1s. Port 0 also inputs the code bytes during EPROM programming.
External pull-ups are required during program verification during which P0 outputs
the code bytes.
P1.0 - P1.7 1 - 8 2 - 9 40 - 44
1 - 3
I/O Port 1: Port 1 is an 8-bit bi-directional I/O port with internal pull-ups. Port 1 pins
that have 1s written to them are pulled high by the internal pull-ups and can be
used as inputs. As inputs, Port 1 pins that are externally pulled low will source
current because of the internal pull-ups. Port 1 also receives the low-order address
byte during memory programming and verification.
Alternate functions for T89C51RB2/RC2 Port 1 include:
1 2 40 I/O P1.0: Input/Output
I/O T2 (P1.0): Timer/Counter 2 external count input/Clockout
2 3 41 I/O P1.1: Input/Output
http://ww1.microchip.com/downloads/en/devicedoc/doc4113.pdf (http://ww1.microchip.com/downloads/en/devicedoc/doc4113.pdf)
-
Thanks very much for the pointers! I'll continue looking. One simple thing might be corrosion on the MCU socket and PLCC pins - there was definitely moisture in the unit. However, I can't see any and this area of the PCB was quite clean. I sprayed some IPA on it and nudged it, but have a proper PLCC extractor tool on its way so i can remove and clean it.
I'll try tracing back where the A and AD lines route to. All of the digital chips I can find are serial: MAX5541 DACs, AD5263 'digital pots', AD77188 ADC and PCA9555 GPIOs, all serial. I'm not sure what AD0-7 will be used for. There is no external memory.
Another thing I could look for is testing some of these lines from power on to see if they are operational at some point. Once I remove the MCU I could also check the resistance measures the same on each similar pin.
Are there data and address pairs, like A15-AD7 and A13-AD5.
Then A11-AD3 is missing and instead there's A12.
I didn't quite follow what you meant by the pairs?
Dang,
I missed the WR, it's active low.
So normally it should be high and 1.1V is pretty low.
But it is also a port pin so it can be ok.
In case of external timer T1, it is incremented during falling edge.
But it also is also a port pin.
Back in the day when PLCC pliers were missing it was tempting to crank the chip up.
The socket can't stand that.
Maybe you can disconnect some pins down the road.
Using instructions like read from external memory are naturally address out and data in.
There address is outputted first and then notALE is reading the data.
If real address is not used then no need to latch anything either but ALE is there anyway.
High side of the address is also maintained during data part of the instruction.
You said there are some optos.
Connections to and from the MCU should be fairly easy to check.
It's not unheard of either that MCU pins are used uncommon ways.
Like a port pin for RD/_WR function.
-
OK, I got my PLCC extractor. I removed the MCU and cleaned the pins and socket with IPA. There was no visible dirt and reseating/cleaning hasn’t made a change in behaviour. I was hoping for a change in luck :(
I measured the resistance of the MCU pins and socket (circuit) pins to ground. MCU pins seem consistent, mostly 470k or so. The circuit pins are much less consistent, some 2k, some 5k, P3.7/RD was 1.6M and P3.1/TxD was 9M. I suppose it indicates these are used for different things. There is nothing the struck me as short or open. :-//
It's not unheard of either that MCU pins are used uncommon ways.
Like a port pin for RD/_WR function.
Yeah, given that there is no external memory, or indeed anything I can see that is addressable with 8-bit parallel data, so I expect these ports are all being used as GPIO. I’m not so sure about P3 as there is the serial port there. So, I suppose specific guesses about pins like WR/RD may not be meaningful. Note that INT0, INT1 are active low and both low, but again, could be port pins i suppose?
So far, I found that both PCA9555 GPIO chips have SDA connected to MCU A9 and SCL connected to MCU A11. One of these chips is the front panel, which is not responding.
You said there are some optos.
Yes, there are loads of optos…
• 2 x 6N137 10Mb/s data ones (https://www.vishay.com/docs/84732/6n137.pdf (https://www.vishay.com/docs/84732/6n137.pdf))
• 17 or more x NEC 2561L high gain single transistor ones (https://media.digikey.com/pdf/Data%20Sheets/NEC%20PDFs/PS2561.pdf (https://media.digikey.com/pdf/Data%20Sheets/NEC%20PDFs/PS2561.pdf))
• 4 x HCNR201 analog ones (https://www.mouser.co.uk/datasheet/2/678/AV02_0886EN_2021_06_25-2902150.pdf (https://www.mouser.co.uk/datasheet/2/678/AV02_0886EN_2021_06_25-2902150.pdf))
I have checked the diodes of these on diode-test. I could go through and check the transistors by powering the diodes and measuring the resistance. I guess these parts are likely-enough to have failed, and maybe some could crash the software...
Connections to and from the MCU should be fairly easy to check.
Tracing the board isn’t very easy in this section. Seems to be “only” double sided, but thin tracks, lots of through-holes, and SMD components mounted both sides. On the positive side, I think I can identify pretty much all of the ICs.
So next things I'll do are:
• Test the transistors of the optos- Update, done for all but 2 of the 2561L, test at 90 Ohms on. Can't test the high speed ones.
• See if I can find where pins 17, 18, 40 go since they are not at valid logic levels.
• See if I can see any initial activity on some of the 'stuck' pins.
-
How is the base of that Q25, should the FET be open?
If it is a crowbar it is controlled by something simple and out of MCU.
There are so many optos that some must be directly connected to MCU.
Maybe you should just assume that short between opto and MCU pin is a legit connection.
Can you figure out the exact MCU variant of 8051?
Since I2C is a bus and there are many chips it's convenient to have a supporting MCU.
It can also change some other pin operations.
-
How is the base of that Q25, should the FET be open?
If it is a crowbar it is controlled by something simple and out of MCU.
I initially focused on this area, because I thought that given it is dissipating quite a bit of heat, there must be a fault within this circuit somewhere. See the attached diagram (it may have errors since it was difficult to trace).
I think the circuit around opamp (a) is designed to limit the conduction of Q25 so that it is safe. The main PSU is a beast - capable of delivering 33V/25A, so shorting it would be explosive!
At startup and shutdown (power remains present for a few seconds), the main O/P is at 0v. Due to this the - input of (a) is low and Q25 is forced into full conduction, gate is 12 to 13.5v at this point. When the output comes on (seems to be set to 14.00v), the voltage at Q25 S 0.29v, resulting in 0.390v at - of (a), compared with reference of 0.395v at + of (a). This results in the output being 4.25v, putting Q25 into partial conduction, regulated with negative feedback from the two 2.4 ohm resistors in series with Q25.
So in practice, Q25 G is being driven by Opamp (a). Opamp (b) is not sinking current through D61; D61 anode floats at 4.25v as per Q25 G. This is because the 'I Share' input remains at 0v. I believe this should be high logic level, i.e. above 0.15v provided by R336/R279. This would force Q25 G low and turn it off.
In conclusion, I thought this whole circuit is fine but the 'I Share' input should be +5v during normal running. I call it I Share as i traced it through to this pin J1_16 on the analog programming input. It is also connected to other items that I haven't been able to identify. I can't really make full sense of this though, but it was leading me to think the problem in the logic circuitry (given also that front panel is dead).
J1.16 CSH Current Share. Used to hook up units for current sharing. Output
from master unit. Slave units should be left open.
There are so many optos that some must be directly connected to MCU.
Maybe you should just assume that short between opto and MCU pin is a legit connection.
Yes indeed. Some of them isolate between sections of the PSU, but some must hook up to the MCU. However, all the optos seem fine and all of the other sections of the PSU seem to be functioning correctly, so I'm still drawing a blank there anyway. So far I've just found the connection between the GPIO chips and the MCU.
Can you figure out the exact MCU variant of 8051?
Since I2C is a bus and there are many chips it's convenient to have a supporting MCU.
It can also change some other pin operations.
I'll continue looking at the suspect pins and see if in can work this out. Thanks for all the additional pointers! Much appreciated.
-
Hi, there is a reset to factory settings precedure described in the manual. Might be worth trying.
-
if the PCA9555 is driving the display I would configure it as 8 output for the 7-digits+dot and 2x4 output as digit select (because there are 2 displays with 4 characters). can you measure anything meaningfull on the outputs?
-
Hi, there is a reset to factory settings precedure described in the manual. Might be worth trying.
Thanks, yes, the procedure I saw was to hold down both front panel buttons. I tried this and it didnt seem to do anything. I can't get any response from the front panel, nor do any of the LEDs even briefly flash - there are lights in the panel/button to indicate the output being on. The output is on, but the indicator is not lit.
-
if the PCA9555 is driving the display I would configure it as 8 output for the 7-digits+dot and 2x4 output as digit select (because there are 2 displays with 4 characters). can you measure anything meaningfull on the outputs?
I'll try investigating this more to see if there is ever any signal on the serial data/clock lines and maybe measure internals in the front panel. Do you think it would require communication to be initiated from the MCU? I can try looking for a signal when adjusting the front panel controls. There are 2 9555s connected with SDA, SCL together going straight to the MCU. One is the front panel, the other is in the main logic / control circuit.
So overall current symptoms are:
* Main output is enabled, power sections all seem fine, but:
* OVP crowbar is at least partially on
* no display / response
* no response on USB (maybe config / user error)
* many MCU connections seem inactive
-
My guess is that during that 100ns of RD the MCU tries to find a missing control input.
Even more so if burst of ALE is in sync.
Since I2C is silent you can put it aside for now.
There is a more major thing that is preventing future operations.
But if output voltage is meaningful the whole thing is somewhat operational anyway.
Means also that MCU is not really needed if nothing is changed, beside those control inputs.
So what MCU must see before it can continue.
Maybe the cause is as simple as one dead opto.
-
My guess is that during that 100ns of RD the MCU tries to find a missing control input.
Even more so if burst of ALE is in sync.
Yes, makes sense.
Since I2C is silent you can put it aside for now.
There is a more major thing that is preventing future operations.
One of the 9555s is interfacing to some parts of the PSU (could be the optos etc.), so I wasn't sure if it is cause or symptom. There are also 3 DACs and 1 ADC with serial connections. I havent checked signals but I guess are communicating somewhat.
But if output voltage is meaningful the whole thing is somewhat operational anyway.
Means also that MCU is not really needed if nothing is changed, beside those control inputs.
This is interesting, because the unit is 100% digital control. The output is fixed at exactly 14.00V (max is 33v) as though it has been programmed so. This must come from the MCU - there is no analog control. The other thing is it does have a 1-2 second wait before the output is enabled, which again I would think is controlled by the MCU. It should have shown 8888 on the display at this point though.
So what MCU must see before it can continue.
Another thing is that many fault conditions should result in an error message (lots described in the manual), so something "unexpected"
Maybe the cause is as simple as one dead opto.
Yes, I very much expected this, but I have checked almost all of them (2 have to wait until I disassemble it again) - both diode and then fwd bias diode resulting in transistor resistance changing from few k or more to 90 Ohms. I've also tested pretty much every diode and transistor I can find. |O
Initially I thought I'd fixed the whole thing by fixing the internal supply (TOP224YN - which was dead), then I thought the crowbar was showing the way to the remaining fault.
I guess either:
* as you say there is some signal the MCU is blocked on during startup, or
* MCU is faulty, i guess could be corrupted firmware etc.?
Next on my list is checking the 3 MCU lines that were not showing valid logic levels. I've checked a few variants of 80C51 that are available in PLCC-44 and not surprisingly they have the exact same pinout, specifically none I found appear to use the port pins as analog I/O.
Update:
* pin 40 is connected to the collector of an opto coupler transistor, so 0.14v is fine - transistor on
* pin 18 is connected to anode of an opto coupler diode, so 1.1v is also fine as this is the normal voltage drop when conducting
* pin 17 at 1.72v, haven't located...
-
Are you sure you've not messed with pin positions?
AT89LP51 have some nice alternatives.
-
Are you sure you've not messed with pin positions?
I don't think so... all the 80C51 variant PLCC-44 datasheets I found have consistent pinouts. I'm matching locations of Vcc, Vss, Xtal, Reset and see correct behaviour on these pins.
AT89LP51 have some nice alternatives.
Thanks! So, looking at the AT89LP51 datasheet (http://"https://ww1.microchip.com/downloads/en/DeviceDoc/doc3709.pdf"), the PLCC-44 pin package does have the same pin designations. Perhaps different behaviours on the port pins though?
So far drawn a blank on two of the 'suspicious' voltage levels as these are actually fine given the behaviour of the optocouplers they're connected to
-
The max1232 watchdog has an inverse strobe input on pin 7 (if it is the DIL8 package). If there is no signal on this pin then the max1232 will reset the mcu (I presume it is connected to the mcu... what else would it reset?)
Can you check the signal with a scope on that pin and trace that back to the mcu? If there is the signal, and it comes from the mcu then you know there is at least some software running on the mcu. Datasheet of the max explains what the signal should look like depending how pin TD is connected (pin 2 if DIL8).
-
sorry i didn't notice you mentioned some mc14489 where driving the displays. that makes it a little easier to check as these are serial too (but not i2c) and should receive some data (pin 12) and clock (pin 11).
if there is no data /clock then the mcu probably fails on providing it. if there is data/clock but no output then the mc14489 are death unless the data is garbage but even then I would expect something on the displays.
is the mcu clocked correctly (22mhz?)
-
Found this in the manual. As there is nothing on the displays i don't think this is relevant but you never know:
Local lockout is a feature that allows the front panel to be locked so that accidental button presses are ignored. This feature is often used to lockout the front panel when you are controlling the power supply from a remote location. When in local lockout mode, the front panel will display LOCL Loc whenever a button is pressed or a knob is turned.
-
You have probably checked that already but I ask anyways because I myself might have not: the display and drivers do all receive Vcc and gnd? I suspect the display is on another board than the mainboard, have you checked for a bad or broken connection/plug/cable?
-
I made some progress... first, I found an SMD resistor on the front panel which was dry one end (due to corrosion). I fixed that and now the display does come on. It shows 8888 8888 (except one segment not working), but it does not proceed to boot up. Still no response to the controls. |O
The max1232 watchdog has an inverse strobe input on pin 7 (if it is the DIL8 package). If there is no signal on this pin then the max1232 will reset the mcu (I presume it is connected to the mcu... what else would it reset?)
… then you know there is at least some software running on the mcu.
Thanks! That is a very good suggestion. Its making me doubt my original observation… I’m sure Reset was low, but now it is giving a 500ms reset pulse every 1.7s; the ST signal is NOT present (always high). I previously checked the xtal pins show 22MHz OK.
I made a somewhat interesting discovery though. If I power up just the +5v internal logic supply by hooking up an external PSU, the display alternates between “8888 8888” and “Err 15U” (see pic). Watching the above video of one working, I can see the normal operation is:
- "8888 8888" for about 1-2 second
- "PSU On" message appears briefly
- Show Voltage / Current
So its like mine is running its startup routine and encountering an unhandled error. In this case there is still no ST signal, same reset pulses. It's weird, it must be running some code to send the error message, but not getting very far at all if it doesn't acknowledge the reset to the watchdog. I also disconnected the front panel and tried that. Still stuck in reset cycle. There are a bunch of messages listed in the manual but the entry for this is just "Err: Error(debug)".
I think I will do more measurements with just the +5V logic supply on as it’s a lot safer! That would also allow me to probe the underside of the board and not having to keep taking the board in and out of the case. Also, saves the crowbar MOSFET heating up. In this state, it may be failing for a different reason but I still think the infinite loop reset cycle is not the normal designed error state. Idea - "Err 15U" might mean Error 15v, indicating the +/-15v supplies are down, which they were in this test. These are normally supplied by 78L15/79L15 with shared ground to the +5v. I could power these up too as they are used for the opamps and analog circuitry. I don't think its likely to damage the 78L/79L regs by powering the output. It might give some more clues...
So overall, I still wonder if the problem is the MCU or external to it...
My guess is that it isn't state of one value like an Opto, otherwise this would generate a handled error. Maybe more likely that it doesn't succeed with some serial comms or it is corrupted onboard ROM or EEPROM.
* MCU execute code and make some serial comms with display and DAC. I suspect the 14.00V output voltage is from setting in EEPROM.
* Is encountering unexpected condition, does not proceed to toggle ST to watchdog.
I also traced quite a few of the connections to the MCU. In short we have:
• 3 DACs
• 1 ADC
• 2 GPIO
• 1 EEPROM (4k serial, type 93C66)
• A few opto couplers
Looking at the active Chip Selects to the above and my signals before it seems to be accessing the EEPROM, maybe not the other devices but I can now recheck this.
-
With AT89LP51RC2 you have some new options.
Though no idea how old this construction is.
INT0 and INT1 are active low and can be level triggered.
So if INT0 is level triggered its low level will interrupt constantly.
But those same pins do also MCU wake up things.
-
With AT89LP51RC2 you have some new options.
Though no idea how old this construction is.
The date on one of the manuals (Rev B) is 2009.
INT0 and INT1 are active low and can be level triggered.
So if INT0 is level triggered its low level will interrupt constantly.
But those same pins do also MCU wake up things.
I haven't found where these go... will try to trace them. These are also labelled as P3.2, P3.3.
So far I found P3.0 (RxD), P3.1 (TxD), and P3.6 (WR) go to opto isolators. 3.0 & 3.1 are connected as inputs and 3.6 an output.
I wonder if the port (e.g. all of P3) has to be either used as GPIO or as the standard functions (RD, WR, RxD, TxD, INT0,1 etc)? Is it possible that INT0/1 are used as INTs but the other port pins as GPIO?
-
Model AT89LP51RC2 manual has section 12 for port pins and they are port X pin Y style.
There's also partial 3rd possibility, remap.
New version has also POL instead of EA for reset polarity.
Your EA is high so new version RST is active high and so no help for chip identification.
One possibility is with pin 12 (SDA), since it's different than other steady port 4 pins.
-
Pin 10 is connected to the Reset output on the Watchdog MAX1232, so this pin does line up with the standard arrangement. Does that help identify the variant?
I have connected up the +/-15V supplies as well as +5V. Now the display stays on 8888 8888, so "Err 15U" does indicate loss of the 15 supply. Shows the MCU is doing something, but its getting stuck somewhere after this basic check.
Since I now get the same results from powering up just these internal lines, it does let me experiment with the high voltage sections off.
I was using the Scopemeter before, but now I've tried with a 'real' scope, I can see the digital signals better and found some of those I said were static do carry signals, for instance the GPIO serial data
-
OK, MCU is alive! 8) After probing more with the scope I found there were pulses on GPIO SDA but just a bit of noise on SCL. Turned out this was a bad pin (27, A11) on the MCU socket. I bent and cleaned the pin and now it boots and there is proper communication with the front panel. First I saw "AC Fail" when I had powered up the internal rails from the bench PSU.
I plugged the AC back in and it now almost works. It shows "Fan Pr0" and indeed one of the fans isn't running. Not too surprising as the fan had a lot of dirt and corrosion. When i rotate the control knob it will show settings and I see it is indeed set to 14.00V so that fully explains why the output was 14v!
Despite it seeming to shutoff the main output now, the crowbar's heatsink is still getting very warm, so that is my remaining concern. I'll try to fix the fan and come back to that.
List of faults so far:
- TOP224YN switching regulator dead - loss of internal power
- SMD cap in PFC circuit corroded / dry - PFC not running
- SMD resistor in display corroded - no display
- PLCC socket damaged / dirty - MCU won't boot
- Fan not working - PSU in fail mode
- One 7 segment LED faulty
Ironically the mfr promotes this range as highly reliable, and the tamper sticker seemed to be intact when I got it...
-
Very good.
The thing has been in a hostile environment, at least sort of.
I wouldn't be surprised if that missing segment was also a bad contact.
It seems that you should change to finding disconnected parts instead of faulty ones.
-
Yes, this is the repair that keeps giving!
There is another problem... in the manual it says Fan Fail should not switch the output off, but it has. When the MCU wasn't running properly I was seeing +14.00V on the output. Now I'm seeing 14.00v in the display and 0v at the output! The PFC is no longer running properly... its sending bursts of pulses resulting in only 280v output. Still, at least I know the regulator IC and can have a stab at finding this (last :) ) fault.
-
Maybe working I2C just put startup so much further that it showed the message and saw the crowbar.
-
Excellent progress :-) Don't give up, you're almost there :-+
Have you tried USB/serial/ethernet again now you know the MCU is alive again? Maybe there is some info there. You also might try that factory reset (not a full reset that would erase calibration data too if I recall well). As there are so many settings on that thing it might be in a somewhat weird configuration.
Replacing the fan, even with a temporary unit that does not fit would at least clear the error and make sure this is not the cause. Do you recall it was working when you had the 14V output without display?
As there was 14V output before and not anymore it sounds like something 'new' has been broken or is simply miss-installed. Connector loose, bolt missing.
-
If that crowbar thing is effectively a crowbar, under what conditions would it 'short'?
- On my HP PS it kicks in when the output is turned off so it pulls to 0V as quickly as possible. This does not match the 14V on the output you had previously, but it does match the 0V there is now.
What happens if you configure the output voltage to something very small/high.
-
Excellent progress :-) Don't give up, you're almost there :-+
Thanks! Yes, I'm pleased the MCU has woken up!
If that crowbar thing is effectively a crowbar, under what conditions would it 'short'?
- On my HP PS it kicks in when the output is turned off so it pulls to 0V as quickly as possible. This does not match the 14V on the output you had previously, but it does match the 0V there is now.
So it has two modes of operation. There are two stages: startup/shutdown and normal run. With reference to the diagram I posted, the comparator (a) outputs a very high level when the output is off at startup/shutdown since the + input is fed from a voltage divider from +15v and the - input from the PSU output. So, crowbar is full-on at startup/shutdown like the HP.
What is unclear is the purpose of the negative feedback in (a) which keeps Q25 in semi-conduction if the input to (b) - is 0v. Strangely I found this same control line alters the fan speed.
As you suggested I'm just going to hack it so that the fan error clears - it has a shunt on each fan.
Replacing the fan, even with a temporary unit that does not fit would at least clear the error and make sure this is not the cause. Do you recall it was working when you had the 14V output without display?
No, this fan had bad internal corrosion and never worked. I found it was partially shorted. I think it might occasionally go open as well, so maybe the fan error may not have been present initially. This fan being shorted might explain the original fault of the switching reg failed (it feeds the unregulated voltage to the fans).
As there was 14V output before and not anymore it sounds like something 'new' has been broken or is simply miss-installed. Connector loose, bolt missing.
Not as simple as a missing connector, there are very few - just one large PCB and a front panel. I think it could be the MCU putting it into shutdown mode though. I'll clear the fan error then experiment with the controls and see if the o/p will come back on.
-
Close, but not there yet...
I hacked the fan protection. It uses a current shunt for each fan and opamp comparator. I pulled the input of the opamp such that the failed fan appears OK, and unplugged the dead fan.
* Fixed the 7-segment display by cleaning as it was socketed. Output enable button also didn't work at all, after spraying with IPA and agitating seems to work.
* I can navigate through the menus and program values
* I did a soft reset which clears the set values back to default
* Voltage and current program values can be set, as can all the other settings.
* Output can be enabled on the front panel, output LED and CV LED are on BUT the output is still 0.0V |O
* PSU voltage readback on the display is also 0.0V
PFC is now running fine: 370V DC output. I think it was put into shutdown before due to control from the MCU. Now I have to look into the control to the M51995AFP switching IC I suppose. Presumably the switcher is OK as it has worked before, but who knows!
This time, the crowbar is not the problem - there's no output across the main rails at all
-
Is the crowbar FET still on, should it be?
The device has so many optos that you can expect feedbacks from practically everywhere.
Means that what ever you do can also affect somewhere else.
Maybe you should once again measure voltages between MCU socket pins and chip pins.
For zero levels use AC area if you can't trust resistances.
Can you go back to that output voltage on situation?
It's probably too far away but then you could check what MCU pins are different.
-
Is the crowbar FET still on, should it be?
Yes, this has not changed behaviour. I checked that the control input to this circuit (opamp (b) - ) is still being held at 0V all the time which means the gate is driven by opamp (a) comparator. Q25 MOSFET will be in full conduction (gate ~ 13v) but D-S voltage is 0.0V, so no effect. Judging from the previous behaviour this should sink a bit of current but not enough to trip OCP etc. I've disabled OVP, OCP on the front panel. So, I think the crowbar circuit is not instrumental in the current behaviour.
The device has so many optos that you can expect feedbacks from practically everywhere.
Means that what ever you do can also affect somewhere else.
Yeah indeed! I guess the general setup is there is a control line from MCU and feedback return to it. When the MCU was crashed it wouldn't respond to the feedback, but now it is. I'm sure there are a number of things that could result in it shutting off the output but it is odd that it doesn't show an error condition. Previous behaviours were error conditions (No +15V, No AC, no GPIO).
Maybe you should once again measure voltages between MCU socket pins and chip pins.
For zero levels use AC area if you can't trust resistances.
Can you go back to that output voltage on situation?
It's probably too far away but then you could check what MCU pins are different.
Both great ideas, thanks. However, I never was able to measure resistance pin-socket because I can't reach a probe through the very tiny gap in PLCC socket. I've been probing the socket (i.e. external circuit). I did remove the MCU and check resistance of its pins to its ground pin, and same for the circuit.
To go back i'd have to try to put kaptan tape over the MCU SCL pin. That is a really good idea for sure. However, the overall behaviour is quite different and I only traced some of the MCU pins.
For now I'm going to try to trace a bit of the M51995 circuit (switching controller). It is hooked up to 3x 2SK2611 MOSFETs. As expected, they have no signal on the gate - should be PWM. If i can find the control lines to this, then I'd know where to poke around for differences in behaviour.
-
My guess is that everything is fine with the switcher.
Earlier it was putting 14V out as was requested.
Current limit was also so that crowbar didn't matter.
Now situation is different and it is ordered off.
So it's a result.
Same with the crowbar.
It's operation has not changed.
But it's also a result.
Now when you can communicate with the MCU through the front panel you know that both are generally fine.
But you are communicating with the internals of the MCU.
All those I/O pins are still generally unknown.
You need to get to the situation where you can be sure that all MCU pins are really connected and operational.
PLCC socket has a one sided spring effect towards the chip pin.
For larger chips this socket type is not very common for a reason, there were also some generally bad quality issues.
If you can put cleaner drops on the connection point you may have some visual effects how the connection actually is.
You can also do some visual estimations by eyeballing the empty socket.
Everything should obviously be level but they are not, but don't over estimate either.
If you need to bend a pin, too little and it wont last, too much and it will bend under when you put the chip in.
-
My guess is that everything is fine with the switcher.
Earlier it was putting 14V out as was requested.
Current limit was also so that crowbar didn't matter.
Now situation is different and it is ordered off.
So it's a result.
Thanks, yes, after I traced out all of the crowbar I can tell the problem is not that area but the control line going in to it. I was just going to do enough tracing on the switcher to understand what the incoming and feedback signals to the MCU are. So far I can see it has 2 standard optos going in.
There will be plenty of measurement of the output voltage and quite complex remaining circuit with 8-input ADC and at least 2 more quad opamps. I guess the ADC reading is fine, because (a) the analog readback signal was inline with the old 14v output, (b) the voltage readback of 0.0v now is correct.
Not only are there 3 DACs, 8 input ADC but also 2 quad 'digital potentiometers' and some digital->analog switches. Its hard to see how they can have made a single output PSU so complex!!
All those I/O pins are still generally unknown.
You need to get to the situation where you can be sure that all MCU pins are really connected and operational.
Right
PLCC socket has a one sided spring effect towards the chip pin.
For larger chips this socket type is not very common for a reason, there were also some generally bad quality issues.
If you can put cleaner drops on the connection point you may have some visual effects how the connection actually is.
You can also do some visual estimations by eyeballing the empty socket.
Everything should obviously be level but they are not, but don't over estimate either.
If you need to bend a pin, too little and it wont last, too much and it will bend under when you put the chip in.
Yes, so I could tell that the pin feeding SCL was slightly different in terms of its position to the others. When I fixed this I also inspected the others and tried to clean them all up with IPA. Of course, doesnt mean that there is not another bad one. There are also some PCB layer through-holes that have some corrosion but I haven't yet found any open circuit.
I like your idea of going back to the situation where the output was enabled by re-blocking the GPIO SCL. I'm intending to trace the control of the switcher to see where to look, then break this again if that doesn't directly unearth the problem.
Thanks again for all your suggestions in this ongoing saga!
-
My part is easy, and not very energy intensive, but middle layer corrosion is a bad rap, luckily all power holes are usually full.
Demo circuit for M51995 had 3 optos, on/off was one, current limit was trafo but it can also be an opto.
What AD/DA functions there could be.
Voltage, current and temp are obvious A/D and all kinds of internal voltage adjustments are clear for D/A but it's still pretty much for a single output.
Can you see any connector variations or so around the PCB?
Maybe it's a general module for varieties of models.
Are there any pin headers or other jumper like things?
Maybe a face plate and some jumpers can change the model.
-
My part is easy, and not very energy intensive, but middle layer corrosion is a bad rap, luckily all power holes are usually full.
Thanks!
What AD/DA functions there could be.
Voltage, current and temp are obvious A/D and all kinds of internal voltage adjustments are clear for D/A but it's still pretty much for a single output.
There is also analog programming and readback so that's part of it. There is overtemp cutout which can be enabled/disabled via the MCU. There are 105C cutout switches on the two main heatsinks, so I think it is just on/off. It means the behaviour now is another "unexpected" fault since it doesn't register error with MCU
Can you see any connector variations or so around the PCB?
Maybe it's a general module for varieties of models.
Are there any pin headers or other jumper like things?
Maybe a face plate and some jumpers can change the model.
I dont think so. See pic. There is this one huge PCB plus small front panel which is just the display and controls. There are little or no "optional parts". There are just two unused connectors. One a 10 pin low voltage one CN10 near the RS485 section. There is optional LAN & GPIB which this unit doesn't have, so pretty sure the connector is for that.
Aside from that a 2-pin connector right by the optos on main switcher - J3. I guess its a test point or shutdown input for testing. Still haven't explored this bit yet. I wont have time on this over the weekend , so the saga continues!
-
8) Result! I cleaned and bent the MCU socket pins again and now there is correct output! Very accurately regulated too - measures within a few mV
The crowbar is still partially active though, so that is the remaining mystery. I'll post more details of the circuit. It is clearly designed to have this mode where it sinks some current but is not full-on; I don't understand why. It may even be working as intended now. For instance the current sunk into it doesn't register on the current measured. Perhaps it is normal for zero load even, but the heatsink is small and gets pretty hot. Doesn't feel right. Anyway.. progress :)
-
Dam those sockets!
And it's not even wide.
Back in the day there where contracted cushion shaped aluminum supports to counter those bulked cushion shaped sockets.
And that was for computer motherboards.
Initial load is usually static, can be different here since variations are so wide.
Have you tried communicating with it remotely?
RS-232 is clearly easiest.
Manual says that in case of flash checksum failure an error is pushed to SCPI error queue.
It is also happening during boot up, can be cleared by soft reset and is last in the error priority list.
So being able to do a soft reset all higher priority errors must be off.
From the picture:
So all sections are optically isolated, that explains it.
There seems to be also few pico fuses.
Below left bigger trafo is a connector, is it CN33, are there 32 other connectors.
Is there a USB controller between RS-section and Isolated I/O, below xtal.
Chip type can possibly help with computer connection.
A12 in the middle of RS-section.
Doesn't look like 10baseT magnetics and if so shouldn't have equal letter with all other chips.
My guess is that it's a floating power for external communications, I counted 22 optical connections around.
If Ethernet and GPIB locations are combined can it mean that ENET is actually AUI-connector.
That would be pretty old school.
If GPIB is connected through the red CN10 there must be 8 bidirectional optos somewhere, and some controls.
Some are promising but they are under staffed.
-
Dam those sockets!
And it's not even wide.
Yeah! Maybe there are still pins that are not connecting properly (crowbar issue). I tried IPA, maybe I should try contact cleaner or find some useful abrasive
Have you tried communicating with it remotely?
RS-232 is clearly easiest.
No, I'll do that next week. It does have USB - that is an FTDI chip.
Manual says that in case of flash checksum failure an error is pushed to SCPI error queue.
It is also happening during boot up, can be cleared by soft reset and is last in the error priority list.
So being able to do a soft reset all higher priority errors must be off.
I think I did this successfully (display said SrS) but I'll do it again.
There seems to be also few pico fuses.
...
Below left bigger trafo is a connector, is it CN33, are there 32 other connectors.
Yes, I've checked these - one tiny fuse, what appear to be a couple of fusible resistors and two black plastic circular fuses (see just above area labelled crowbar). There are a lot of connectors, since they've labelled incoming mains, switches, rear panel etc. There are only 2 unused ones - J3 and CN10. I presume that if GBIP/LAN module is fitted it will have a PCB perhaps with more optos on it. This unit has RS232,485, USB and Analog voltage control.
So far the problems have all been due to the corrosion apart from the TOP224 switching reg, which I expect overheated from the fan being shorted. I may recheck for the PCB through-holes showing a bit of corrosion, clean up the MCU socket again and look for dry SMD joints underneath (many components mounted on underside).
Thanks again!
-
Soft Reset from the manual,
PSU S rS is displayed for starters and
PSU CLr when done but for 1 second only.
I think you can use decent contact cleaner freely, it's just a regular PCB, so no need to be specially cautious.
But you don't need to flood it, just a wet cotton swab will do.
Back in the day we used all means necessary, but that was usually just for the time before the next machine arrives.
PLCC type of contact is self cleaning, by abrasion when inserting.
So you can do that, but there's an intuitive catch, it only matters there where the contact will be.
Now when you have reshaped those socket pins the contact position of a chip pin is also different, maybe a bit higher.
Irritable things are these contact issues, at least you know where to look next time.
-
Soft reset done; it showed PSU Clr. I think it may be operating properly now... The remaining 'problem' was the 'crowbar' circuit. I wonder this thing is actually operating as intended. It is rather hard to tell. I thought it was not working correctly simply because it was sinking some current and heating up under normal operation, but with no load. All external signs are fine. The voltage is being very accurately regulated and the voltage and current readback is accurate.
After tracing the circuit out, I found it is controlled by a line I labelled 'I Share' on the attached schematic (this is connected to the 'current share output' on the analog I/O). When there is no load, this is at 0v, resulting in no conduction through D61, leaving the crowbar in its 'floating' mode. I found this line is also used to control the voltage going to the fans through a rather crude mechanism of a 5.1v zener (ZD14) going from the reference connection of a 7805 regulator to this line. Further, I found that when there is load on the main PSU output, this line moves up from 0V, perhaps in proportion to the current. This results in the fans going faster and the crowbar easing off. However, I don't have a decent load and the full rated load is 25A so I haven't managed to budge it much, but it seems this could be operating as intended. Note, it can't be tested by shorting the output, because when the output voltage is zero that turns the crowbar on (voltage divider R270, R271, R272).
The crowbar floats given the negative feedback over the two 2.4 Ohm resistors such that it doesn't consume too much power. I wonder it helps regulate the output accurately when there is low load by damping it. I also notice that on the top panel there are more pronounced markings (after cleaning) showing this heatsink has been hotter than the others - see pic. This would certainly happen if the PSU was powered on with no load.
I am intending to replace the broken fan and the working one with quieter and lower power models. This is a 1U unit which has 2 x 42dbA 40mm fans - quite annoying. These are 14CFM. I found 8.9CFM 25.5dbA (http://"https://cpc.farnell.com/multicomp/mc002689/axial-fan-40mm-12vdc-8-9cfm-25/dp/MF68398") or 7.7CFM 21dbA (http://"https://cpc.farnell.com/multicomp/mc002690/axial-fan-40mm-12vdc-7-7cfm-21dba/dp/MF68412")
It is more use to me as an accurate digital power supply rather than a very high power one, but I'll have to check this crowbar heatsink doesn't get too hot. Unlike the 2 MOSFET switcher heatsinks, there is no thermal cutout...
-
Yes, classic crowbar it is not and controlled damper it seems to be.
I'd say that congratulation, you have a sophisticated, almost new and working power supply.
Maybe you can setup your new silent fans to speed up and let the crowbar rest.