Idle Control Technical Analysis

[Strife]

I bought a spare idle controller for my car, and I wanted to see what was inside of it because - well, because. As I suspected, it's basically an entire microcomputer, with power analog output to the idle valve, running in a "closed-loop" mode. I worked with electronics in the same era that these were made. Some observations, and insights I've seen on the 'net:

The unit has a "digital" daughterboard and a power analog output. The digital part uses some early surface-mount components, and the boards are covered by a rather flimsy conformal coating (that was actually coming off in spots, very very bad, especially if it comes off of the die - see below).

The digital section actually uses a microprocessor die mounted right on the board, with a protective plastic cover, the conformal coating was put right over the whole thing. I'm guessing judging by the die size, pins, and crystal selection that it is an Intel 8051 derivative by Siemens. The board is probably programmed for different cars, and then soldered to the analog board during the last stages of manufacture.

Something a little worrisome about this is, that the reason the die is "out there" might have something to do with its erasibility with UV light (there was no true "flash" electrically-eraseable programming back then, just UVEPROM and a few other now-abandoned technologies). If the chip were a hard-coded masked ROM (using a very permanent technology), there would have been no reason to expose the chip like this. Most UVEPROMS of that era did slowly leak a charge, even if kept in completely unlit conditions; the technolgy leaders (Intel, for example) would guarantee data retention for more than 10 years.

I have UVEPROMS more than 20 years old that have their programming perfectly intact (I know this, because they contain a checksum - a sum of their bits + a magic calculated number also stored yields 0). But it would be unreasonable to expect most of these to still work 40-50 years after manufacture. However, I can read these EPROMS, and re-program them (setting the clock forward another few decades) or store the programming data on more permanent media. It is common practice in firmware development (particularly where machinery or safety is involved) to write a program so that the first thing it does is run a checksum of its own code, and throw an error and lock-up in some safe failure mode should the checksum fail.
Suppose that there are 8,000 bytes in the code. This would be about 65,000 bits. If one should fail (A 0 turning into a 1), the module will probably fail.

8051 based Micro's of this era had primitive copy protection and it was often enabled - that is, the code could only be executed and not read out. It was possible to defeat this, although this is now illegal at least in the US. I would expect that this copy protection has been done on this chip.

Reverse-engineering the function of these modules legally will be required in the future if these cars will be seen on the road 20-30 years from now (assuming that there would be any gas to run them, heh heh).