Troubleshooting Macintosh Portable after loading 12V line-- self inflicted.

[campbellashe]

Okay. I was getting excited and tried to internally power and LCD replacement off the J15 connector -- using 4 12 volt lines and 4 GND lines to power a barrel connector and a 12 volt LCD -- yep. Shouldn't have done this. The LCD did power on; but now my computer will not boot. NO smoke; no pop, no obvious overheating.

What is working:

• F1 good
• +12V converter working
• Main +5V present
• +5V reaches RAM
• No hard short on +5V
• No hard short on +12V

Where I’m currently stuck​

The machine has valid power rails, but:

• SYS_RST* never releases
• RESET stays low
• HALT stays low

The CPU never starts executing.

Looking at the schematic, R13 (1 kΩ) connects SYS_RST* to the CPU GLU NORM_RST* signal. My next thought was to lift one side of R13 to determine whether the PMGR side or the GLU side is asserting reset.

Questions​

1. Has anyone seen this failure after overloading the J15 +12V rail?
2. Is lifting R13 the best next diagnostic step?
3. Is there a known failure in the PMGR, hybrid, or CPU GLU that will permanently hold SYS_RST* low while +5V and +12V remain normal?
4. Is there another signal I should measure before lifting R13?

Thanks for any guidance.

 

[Froggy814]

@techknight might know a thing or 2. I couldn't tell you, but I would definetly hope it's not the PMGT or the GLU!

 

[David Cook]

Is there a known failure in the PMGR, hybrid, or CPU GLU that will permanently hold SYS_RST* low while +5V and +12V remain normal?

Yes. I believe there is an analog voltage provided to the PMGR that represents some fraction of the battery voltage. This allows the PMGR to know when the Portable is plugged into an outlet and to be able to measure battery discharge levels. I believe this also allows the PMGR to soft shutdown when levels get too low. My understanding is that if this value gets too high it can damage the PMGR (such that it won't turn on the Portable) or too low such that it thinks the battery is too discharged (and also won't turn on the Portable).

Perhaps pin 52?

 

[David Cook]

On other forums @techknight has said:
"What I need you to do now, is check the voltage at the Hybrid, on the pin literally behind the NMI button. it goes into that Op Amp sitting below. It should hover around 2.2 to 2.5VDC. if it falls to 0, or latches at 5V, the system will NOT stay on.

If that looks good, I then need you to check for roughly the same voltage at the PMU on Pin 52. The signal gets filtered by a low-pass sitting at R151 and C107. if anything is wrong there youll get issues."

 

[campbellashe]

Thanks David. I’ll work on it tonight. Puts my RAM card development on hold…

 

[campbellashe]

Yeah. The pin 52 and the hybrid are the same at 2.7. I'm concerned that I fried my PMGR....

 

[daanvdl]

Before lifting R13, I would first check the reset input of the Power Manager MCU.

Last week I repaired a Macintosh Portable with somewhat similar symptoms. In my case, SYS_POWER never toggled, although AKD activity was reaching the Power Manager.

For reference, I compared the Hybrid/Power Manager voltages with the known-good measurements in Androda’s spreadsheet
https://docs.google.com/spreadsheets/d/1UuimsU50-zfGkfePpQFFvMdw2yRpz3iFfBIIjOgnKow/edit?usp=sharing

Before lifting R13, I would also check PMGR_RESET* directly at pin 18 of the Power Manager MCU while triggering AKD.
On the machine I repaired, PMGR_RESET* was normally high, but during the reset pulse it did not fall low enough to be recognised as a valid TTL-low level.
According to the schematic, the same signal path both holds MCU pin 18 high during normal operation and pulls it low during reset:
PMGRST* from the GLU PIn 62 → S1 pins 4–5 → PMGR_RESET* → MCU pin 18.

The fourth switch section in S1 had developed some contact resistance. The high idle level still looked normal because the MCU reset input draws very little current, but when the GLU tried to pull the line low, the resistance prevented pin 18 from reaching a sufficiently LOW.
Bridging the S1 contact between pins 4 and 5 restored a clean reset level, and the machine booted.

If you can measure clock activity on signals generated by the Power Manager MCU, that is also a useful sign. It suggests that the MCU is receiving power, its oscillator is running, and at least some of its internal logic and output stages are functioning. It does not prove that the MCU is fully operational or executing the correct firmware sequence, but it makes a completely dead MCU less likely.

It may not be the same fault, especially since your failure followed a 12 V overload, but it is a quick and non-invasive check.