ECU Architecture

ECU Architecture

You can think of the basic ECU software architecture as two concurrent tasks that are running continuously. One set of tasks is doing all kinds of things that are not too critical in terms of their timing. The set of non time-critical tasks would include things like measuring a set of non time-critical input sensors like coolant temp and throttle angle.

The other set of tasks performed by the ECU are extremely time-critical. These tasks would be things like:

  • starting an ignition coil charging

  • discharging an ignition coil to cause a spark on the sparkplug

  • starting a fuel injector squirting

  • stopping a fuel injector from squirting

The ECU spends most of its time processing the non time-critical tasks. When it has finished processing all of its non time-critical tasks, it just starts over again. You might get bored checking the coolant temp a few times per second as long as the ignition key is on, but the beauty of computers is that they just don't care. Amongst all this monotony lurk some very important, time-critical tasks. Whenever the ECU processor has to deal with some time-critical event, it stops what it is doing, processes the time-critical operation, and then goes back to the non time-critical tasks right where it left off. In computer parlance, the time critical tasks 'interrupt' the normal processing flow.

To manage the time-critical tasks that need to be performed, the ECU processor has a set of 'interrupt' inputs. When these processor inputs become active, they tell the processor to drop what it is doing and service the critical interrupt. For example, the crankshaft sensor and camshaft sensors are connected to processor interrupt inputs. The processor is programmed to look for changes in the signal level on its crank and cam sensor inputs. This means that whenever a crank or cam sensor signal rises from LOW to HIGH or falls from HIGH to LOW, the processor immediately gets a kick in the pants and goes off to figure out what it should do in response to the new event. The diagram below shows a complete pair of rotations of the crankshaft through four cycles of 4-cycle engine operation, for both front and rear cylinders. For reference, detailed information on how this table was created can be found here. The short version is that the CR (Crank Reference) events correspond to the little bumps on the alternator flywheel.

If you count the number of changes in signal state for the crankshaft sensor, you will notice that each CR event generates two changes to the crank sensor signal:

  1. A falling edge event that signifies the start of the overall CR event. This occurs when the leading edge of the bump on the alternator flywheel passes under the sensor.

  2. A rising edge event that occurs some time later. This occurs when the trailing edge of the bump on the alternator flywheel passes under the sensor.

Since there are 6 CR events per crank rotation, there are a total of 12 changes per rotation. What this all means is that 12 times per rotation of the crankshaft, the crank sensor tells the ECU processor that it needs to drop what it is doing and pay attention to the crankshaft.

Crankshaft Processing

The specific processing that occurs for a crankshaft depends on which CR event the processor is looking at. This means that the ECU gets turned on, one of the first things that it needs to do is to figure out where its crankshaft is. In effect, it does this by ignoring crankshaft events until its sees the falling edge of a camshaft event. That tells the ECU that the next falling edge of the crankshaft sensor must be the falling edge of CR0. As soon as the next falling edge of the crankshaft sensor is observed, the ECU makes a note that it is looking at CR0F where the F means 'falling edge'. From there, life is easy: the next thing that has to happen is a rising edge event on the crankshaft sensor. Since we just saw CR0F, the next crankshaft event has to be CR0R, or the rising edge event of CR0. After that would come CR1F and then CR1R, and so on until another cam sensor event in CR11 would mark the next upcoming CR0F event. This is an important concept, because the ECU splits up its processing duties based on exactly what CR event just occurred, and whether the event is a falling edge event or a rising edge event. The 549USA firmware splits up its duties as follows:

Leading edge CR events

All of the exciting events happen on the leading edge of the rotor protrusion, which causes a falling edge interrupt input to the processor. Certain operations are performed on every leading edge event, regardless of which CR it might be. For example, every leading edge event does the following:

  1. The ECU toggles the tachometer drive signal that gets sent to the speedometer unit. Since this is a toggle operation, it means that the frequency of the tachometer signal is (6/2) or 3 times faster than the engine is turning.

  2. If the ECU does not know where the crank is, it checks to see if it saw a cam event since last time. If so, this must be CR0, and the ECU knows for sure where the crank is.

  3. Calculate how long it took for the crankshaft to rotate through its last 1/2 of a rotation. This can be considered to be calculating an 'instantaneous' RPM, meaning how fast is the engine turning at this instant, even though the instant is actually 1/2 a rotation. While not exact, it is close enough for the ECU's purposes.

  4. Use the instantaneous RPM to decide if the engine is turning really slowly (maybe it is being started), or over 1000 RPM. Make a note of how fast it is going for other software to examine later for their own purposes.

Trailing edge CR events

The CR events that correspond to the tail-end of the rotor protrusion passing under the crank sensor (the rising edge of the crank interrupt into the ECU) are almost completely unused. The only rising edge events that are used by the ECU are CR5R and CR10R. These two events are used to help get the engine started by firing the front spark (CR5) or the rear spark (CR10) "manually" when the engine is going too slowly for the regular spark-generation mechanisms to work properly.

All other trailing edge events are simply ignored. All the processor does is tell itself to wake up as soon as the next leading edge event occurs.

This means that while the width of the protrusion is important for CR5 and CR10, the width of the other protrusions is pretty meaningless. Even the extra long CR3/CR9 protrusion makes no difference to the firmware.

Specific CR Edge Events

Certain other operations are performed on very specific crank edges. (Note: the table is not fully populated yet -- just because an entry is blank does not mean that the ECU is ignoring it...)

And so it went for a few more years. My plan was to figure out the important information that the ECU was calculating and then change the ECU firmware to send that info to the outside world where I could collect it and correlate it with a GPS position for data logging. I got far enough to suit my needs, but I do not know everything about the ECU's innards. At some point, I will explain in more detail where I took things, but for now, it's just a placeholder.