ECU memory strategies

[Ben Beacock]

I'm reworking the code on our ECU and I'm interested in what others have done for memory/storage on their systems in both development and running on the car.

Last year we used an MPC555 and will continue to do so this year. It includes 448K of flash and 26K of RAM on-chip. The code runs entirely from flash and so does development (kinda slow)
I've thought about adding some external SRAM for development, but I wouldn't really want it there while in "production" for reliability reasons.

Anyways, it was less than optimal because I hadn't figured out the flash programming drivers so any changes to tuning involved a complete re-flash of the ECU.

So here's the meat of the question. I have the fuel and injector tables in their own block of flash so they can be wiped out and reprogrammed. Should I make a working copy in RAM so that the ECU continues to function while tuning paramaters are flashed? This might limit the size of the maps and parameters because there is only 26K of RAM which also has to include the stack and other temp variables.
The other option is to have another copy in a different section of flash and to alternate which one is the current working copy. So you would be reading A and updating B. Once you commit the changes, the working copy switches to B and overwrites A with a copy. Then changes are made to A. Hope that makes sense.

[Ben Beacock]

I'm reworking the code on our ECU and I'm interested in what others have done for memory/storage on their systems in both development and running on the car.

Last year we used an MPC555 and will continue to do so this year. It includes 448K of flash and 26K of RAM on-chip. The code runs entirely from flash and so does development (kinda slow)
I've thought about adding some external SRAM for development, but I wouldn't really want it there while in "production" for reliability reasons.

Anyways, it was less than optimal because I hadn't figured out the flash programming drivers so any changes to tuning involved a complete re-flash of the ECU.

So here's the meat of the question. I have the fuel and injector tables in their own block of flash so they can be wiped out and reprogrammed. Should I make a working copy in RAM so that the ECU continues to function while tuning paramaters are flashed? This might limit the size of the maps and parameters because there is only 26K of RAM which also has to include the stack and other temp variables.
The other option is to have another copy in a different section of flash and to alternate which one is the current working copy. So you would be reading A and updating B. Once you commit the changes, the working copy switches to B and overwrites A with a copy. Then changes are made to A. Hope that makes sense.

[Akos]

Ben,

The HC11 I was using for ECU had even less resources. If you are careful with data representation, you should be able to squeeze an engine map in under 4 Kbytes.

For example, there is no need to store ignition timing as a float. Just store it as a single byte. If you divide by 2, you will get +-64deg of timing with 0.5deg accuracy, which should be good enough.

Very fine table spacing is not usually needed either. If you have a decent interpolating function, you should be able to get away with a 32x16 (rpm/load) table for both fuel and spark.

With the HC11 I had to squeeze the entire engine map (fuel and timing) into 256 bytes, which were stored in the EEprom of the chip. I wasn't using 3d tables, so the map could be made considerably smaller.

When developing software/hardware, I found the best to store calibrations in an external serial EEPROM. This way, you can freely flash (or blow up) the micro, without loosing your cal table. Once your software is stable, you can move the cal back into internal memory, and save the extra cost/complexity of the EEPROM.

Cheers,

Akos

[murpia]

Hi Ben,

I have a fair bit of experience with the MPC555 chip, and I think you are right with your first suggestion - making a working copy of your tables in RAM. This allows unlimited cal changes while tuning, without continual wear and tear on the FLASH. There are some very specific limitations on the way you must write to the flash on the MPC555 and in fact I would endorse Akos' suggestion to keep your tables in a separate SPI EEPROM. In particular the timing constraints are very tight so writing FLASH while simultaneously running an engine could prove problematic.

Contact me off-list if you want more info, also I would be interested in hearing more about your ECU: murphynetuk(at)yahoo.co.uk

Cheers, Ian

[B Lewis @ PE Engine Management]

Hi Guys,

We have a fair amount of experience with using Motorola processors in our ECUs. The strategy that we use is to make a working copy of all tables to RAM as soon as the controller is initialized. Tuning the engine simply means changing the values in RAM. These changes are instantaneously valid as soon as they are made with our tuning software. We then have a seperate function that writes all of the changed values to EEPROM when the user tells the ECU to do so. When saving to EEPROM, we shut off all of the interupts, causing an artificial hiccup while the engine is running. This allows the ECU to concentrate on writing to EEPROM without getting confused on the timing of some events. Depending on the number of values that have been changed in RAM since the last time EEPROM was written to, this will cause a small "miss" in the engine while it is running. The advantage of using this strategy is that while tuning, the changes are instant and RAM is very quick and easy to access.

Hope this helps!