Undead Programmable DC Supply - any ideas?

[EHT]

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 . It has digital control and USB/RS-485 interfaces. The general design is fairly clear and it can be seen in .

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)
•   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
•   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) 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) 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) 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. I’ve checked the diodes but not done the harder check of transistor on-resistance.

[EHT]

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

[m k]

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.

[EHT]

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?

[abdulbadii]

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

[m k]

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.

[EHT]

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)
•   17 or more x NEC 2561L high gain single transistor ones (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)

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.

[m k]

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.

[EHT]

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.

[Swake]

Hi, there is a reset to factory settings precedure described in the manual. Might be worth trying.

[Swake]

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?

[EHT]

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.

[EHT]

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

[m k]

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.

[EHT]

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. 

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...

[m k]

Are you sure you've not messed with pin positions?
AT89LP51 have some nice alternatives.

[EHT]

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 , 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

[Swake]

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).

[Swake]

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

[Swake]

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.

[Swake]

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?

[EHT]

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.

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.

[m k]

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.

[EHT]

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?

[m k]

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.