I wonder if there's a way, while a scan tool is connected, to ascertain if the ECU resets / goes through re-initialization. I've never had to look for this occurrence and I'm not certain how to go about it.
I've been wondering the same thing. The first system I learned to troubleshoot at the microcode
level was a PDP-11/70, and as the power came up & ACLO was negated, it
always started running
at microaddress 0200. (Bit 7 set, all others clear in Octal) In the microcode flows this was
identified as 'ZAP 200'.
Back when I was in the first level of support, within seconds I could figure out what was ailing the
CPU that the onsite guy couldn't get running no matter how many boards he had thrown at the
central processor. He was thinking hung machine =
bad CPU with a logic failure.
When I would see it stuck at ZAP 200 I knew that it was a
good CPU waiting for the signal from
the power supplies that there was enough power for it to safely start logical operation. I would
immediately start heading towards the power supplies feeding the CPU, instead of the CPU itself.
****
Apologies for the historical detour, but your statement about a place to look where we could
check for the # of inits that's occurred since the initial Key On would be
extremely informative.
I understand that the ECM/PCM/VCM is a dedicated realtime system, and there's no onboard TOY
clock, so I shouldn't expect there to be a detailed timestamped logfile that I can access...but I sure
wish there was. :0)
Even so, I wish that there was some sort of white paper/SAE paper where the basic overall
HW/SW architecture behind the TBI ECM/PCM and Black Box VCM was available. (And especially
the next-gen 0411.) By knowing this stuff, we could make sense of weird symptoms by figuring
out that something hung at a higher priority was casting long shadows on lower priority processes
that were essential to successful everyday operation. This level of knowledge helps to make sense
out of otherwise counterintuitive system behavior. (!)
So, yeah, if any of the long-time GM ECU spelunkers in here can point me in the direction of this level of
documentation I would be much obliged. For I spent an entire career proving to myself time & again that
it takes a long time to fix something that's not broken. (ie: Troubleshooting success really depends upon
translating detailed symptom observations into a good problem definition at the outset...and the tighter
the better. :0)
PS: There has to be a 'so many millisecond' window where the power has to be perfect in order to not get
a nonsensical result from the POST (Power On Self-Test) routine. Otherwise, you are quickly led down the
troubleshooting rabbit hole. This is one of the holes in the "I'll have the single computer test
itself on the
way up" strategy. (Works fine 99% of the time, but not if there's flaky power being fed to it at the exact
wrong time.)
EDIT: Some systems only test once during power up, while others will continue this level of
confidence testing periodically inbetween injector calculations and spark plug firings. It all depends upon
how many extra CPU cycles are available vs what's needed to keep the engine running. (!)
Good stuff. I look forward to a successful resolution that we can all learn from.
Cheers --