Macintosh Portable finicky after capacitor replacement

[androda]

Fortunately getting data from the LA was really easy.  Plug into ethernet, go to IP address in browser, hey look there are the files.  No complicated or proprietary nastiness to deal with.

This logic analyzer data is not really messed with or organized in any sort of manner.  I just hooked up the pods to my EPMGR adapter board in order and fired it up.  I intend to write a little program to parse out all the bits and organize them into sensible sections, like having all the VIA data lines and PMack/req next to each other to make it easier to look through.

In the attached zip file are:
* A spreadsheet detailing which logic analyzer pod and signal goes to which pin on the EPMGR connector
* The raw binary output files (with state number and raw picosecond timestamp).  These files are literally a million lines long and should not be opened unless your text editor can handle 80 megabyte files.

Looks like MESS has some information about the portable's power manager: http://mess.redump.net/mess/driver_info/m50753-based_pmu

View attachment zipArchivefor68kmla.zip

 

[androda]

Finished my little program, here are the results in CSV output by signal, with VIAD0-7, PMAck, PMReq, PMInt close together for easy comparison.  All signals are included, and these files are over 100 megs.  Not the friendliest for LibreOffice, but it does open them eventually.  Note that I set my LA to consider 2.5 volts to be a logic high, and I am willing and able to try different threshold voltages.

The PMReq/PMAck transitions look OK on the successful boot trace (duh, it boots successfully), and I have no idea what's going on in the boot failure trace.

Success trace:

1. PMReq/Ack stay high (not asserted)
   
2. Signals appear on VIAD(x)
   
3. PMReq asserted (low voltage)
   
4. A short time later PMAck asserted
   
5. A short time later PMReq goes high (deasserted)
   
6. PMAck stays low for a bit, then pops high
   
7. PMReq and PMAck stay high until the cycle starts again with PMReq assertion
   
8. I have no idea what the data lines mean, it looks to me like not much is going on
   

Very orderly, request asserted and acknowledged, then both lines deassert until the next exchange.

Failure trace:

There's a lot more going on here.

• PMReq and PMAck stay low together for awhile (line 224153 to 224353, a period of about 1.5 milliseconds).  But the data lines are pinging all over the place, so this could just be a data transfer protocol.
  
• Line 224459: for awhile we get PMInt strobing on and off for a bit, to 224584.
  
• Line 224920:  We have a PMReq, but PMAck just strobes on and off at about 19 kHz until line 267526.  Sometimes the data lines change, sometimes not.
  
• Line 275509 is where PMReq and PMAck are low all the time, with mostly logic high in the data lines.  Nothing happens after this point, those two are the same until the end of the file.
  
• Line 275591, IWM_CNTRL and SCC_CNTRL drop to 0 and stay there until end of file
  
• VIA_TEST was high until 275510, according to "Apple Guide to the Macintosh Family Hardware 2e" this line "forces the power manager IC to turn on all power supplies".  Referred to as "via.test" and "vtest".  So I guess the VIA uses that to tell the power manager to turn stuff on, and it's not just for internal testing.  It's high for the entire trace of the successful boot.
  

At no point do I see a STOP_CLK or SYS_RST or EPMGR_RST or that sort of thing.

I am absolutely no level of expert at doing logic analysis.  But I see a possible issue in Req and Ack lines between the via and power manager.  Via asserts Req, power manager listens and asserts Ack, and it seems like the via should then deassert.  But it isn't in all cases.  Could it be that the real issue lies in the VIA chip?  I certainly wouldn't put it past both chips having issues due to age and capacitor fluid.

View attachment csvFor68kmla.zip

 

[androda]

Yet more testing around shows that with the power adapter plugged in, that power manager A/D line spikes all the way up to 6.2 volts.  As far as I know, that should stay below 5, with 7.5 volts across the battery resulting in 5 volts on the A/D line.  Makes me wonder whether that over voltage is the cause of the bad power manager behavior, causing something internal to break down or overheat.

I'll be doing the 'sit and wait' test again, with only the battery connected (more likely, my power supply set to 6.3 volts on battery terminals).  Would be nice to know if that is the cause of our problems.

And after doing yet more looking around in those logic traces, the CHRG_ON* line seems to like bouncing between high and low even though the system was on battery power only for the traces.  Starting to point at hybrid module issues along with power manager issues.

Another thing I plan to do is capture some ADB keystrokes on these logic lines to try and understand how ADB commands flow through the power manager.  Helpful for reverse engineering, I hope.

 

[techknight]

The hybrid is bad. It is very common. If the Hybrid isnt stable, no way in hell the PMGR will be. When the charge state switches, the PMGR internally changes the ADC scale and other operations. 

only solution is to find a new one from a donar board. 

I am in the process of potentially engineering new replacements