Problem Statement:
The ROM consumption in a specific Car ECU variant, for a major European OEM, was u/listed by around 96%. The customer wanted to add more features within the same ECU, which needed more ROM.
Our Approach/Analysis:
Initially, we evaluated the op/on of changing the microcontroller with more ROM area, so that even if in future new features would have to be added up, we can do it flexibly.
But the above approach called for a huge cost resulting from the change in hardware and it’s development time. Later, we started analyzing the Memory, optimizing options within the ECU. And, while doing so, we came out with the below solution.
Solution:
There were about 150 configuration parameter blocks of varied sizes within the Data Flash section. These had respective default values stored within the ROM area, purposed for use against corrupt data, received from Data Flash during runtime.
Out of the 150 blocks, around 80 blocks had their default values as ‘0’. So, we decided to take the highest block out of these 80 blocks, and just created 1 ROM default area amongst them, pointing all the 80 memory blocks to this area.
The above solution resulted in saving the space and thus fulfilling the customer requirement by saving development /me and cost. The customer was extremely happy, as they didn’t need to go through the painful cycle of changing the hardware and perform the entire development and validation activities.
Our Approach/Analysis:
Initially, we evaluated the op/on of changing the microcontroller with more ROM area, so that even if in future new features would have to be added up, we can do it flexibly.
But the above approach called for a huge cost resulting from the change in hardware and it’s development time. Later, we started analyzing the Memory, optimizing options within the ECU. And, while doing so, we came out with the below solution.
