I am new on this forum. I am an electrical and computer engineer but I have just started to study embedded systems. I have worked as a engine calibrator for a big automotive industry but I want to move on and go to the next level if possible. I have read some ECU types by using some specific tools. They used infineon tricore, MPCx5xx and others (Renesas as far as I can remember). I am really novice on electronics but I have started to mess with an ARM CORTEX M4 TM4C123GH6PM. As far as I can understand there is a memory map. 256 KB ROM where the C instrctions are stored, 32KB RAM where data and variables are stored, some other memory for I/O and for internal I/O (please correct me if I misunderstood something). Now, as a tuner I used to modify just a specific area of memory where the "maps" were stored. My question is:Are these maps stored as data/variables in RAM (EEPROM maybe not sure)?How can you identify maps through hex code and find their use?(like a turbo pressure controller map for example or a torque limiter).Is there a pattern?Is there a specific procedure that has to be followed?

Sorry for my silly questions but I am intrested in having a deep understanding on how ECUs are built,how are they programmed by OEM engineers and how they can be reverse engineered.It's an embedded systems so it has to be structured.It's not science fiction

The TI controller you're referring to is an empty micro controller. It's like a computer without any OS, let alone applications you want to run. The software that runs on it is proprietary to the ECU vendor, specific microcontroller chip chosen and the hardware it runs on.

Firmware is usually programmed in a language like C, and in particular for automotive restricted to something like MISRA C, because they are safety critical components. Please don't confuse "programming" and programming. If you press program on most of those tuning tools, they probably mean uploading a new image onto the ECU with all the mappings. With programming I mean writing the firmware that does all the computations, logic, etc. And like I said; that's a highly specific piece of firmware.

As such, how ECU mappings are stored is probably specific for each vendor. I think most car manufacturers often don't bother making these kind of ECU's anymore, and luckily for tuners there is some overlap between OEM's. However, each OEM can decide on their own how to store their mappings. If they really want to be a bastard, they could even encrypt them (I wouldn't be surprised if that is already happening).

The mappings are most often a lookup table to translate input values along a curve to a desired output, with some interpolation applied (like linear or bicubic), and then they are used probably somewhere inside the ECU for actuators, control loops, and a whole slew of other stuff.

I'm not sure how people reverse engineer these things. I'm sure car manufacturers have their testing & engineering tools for these devices, maybe the ROM read/write algorithms & ID tables are ripped out of there, rather than the ECU firmware. Reverse engineering firmware is not a trivial task, and requires a lot of programming and computer experience to pull off.

Also, the "memory map" you're referring to on the MCU is like the memory address space of that chip.

Thank you for your reply mate. This information is really useful to me. So there isn't a specific procedure that I have to follow so to be able to find and calibrate maps. In addition, as you mentioned, the way automotive companies create maps and firmware is unique so I suppose this will be a really tough task for me. Ok to go on, because I am a total novice and this seems a really difficult task to begin with, do you have any advice on how to start?I have started to watch some embedded software lessons online which are done by Mr Varvano (Texas university) and I have started to study C as well. Any guidance would be helpful.Thank you

If you want to learn about engine management systems, you might check out Megasquirt. It's an open source fuel injection system, all the code is available to see how everything works. I've been running it in one of my cars for several years.

Hi mate. I know how to map a vehicle. I have worked as an engine engineer on motorsport. I have tuned many standalone ECUs like Motec, Pectel,Haltech etc. I am not intrested in learning on how to properly tune an engine's vehicle,transmission etc. Moreover, this is not the appropriate forum for this task. I want to learn embedded systems and more specific on how to be become able to understand OEM ECU (stock ECUs). Standalone ECUs are very intresting but their mapping procedure is an easy task because you can log the vehicle in real-time on the dyno and on the road, then you can set your values while looking live at your sensors, you can set your PID controllers etc. On OEM ECUs all these are impossible (at least for me) because I can't identify the appopriate maps in the memory. It's like "hacking" the ECU and I really dont have a clue on how to do such a difficult thing

It's pretty much only bosch, denso and magneti marelli who bother writing the firmware for ECUs... not many other big players left. They also do all the research. And they write it according to the specifics the manufacturer requires

Good to know but I have met a lot of Siemens ECUs as well. I think that the most ECUs that I have met are Bosch ME 7 MED 9 and MED 17 + Siemens (SIMOS,VDO etc.).So if you want to find maps-data and on which addresses they are stored, you have to find a file from the manufacturer (like dammos which are all in German and they are a pain in the aas to be understood).

Automotive ECUs are widely used and there is enough overlap over time and models that people have gone to the effort to reverse engineer the code and identify the tables ("maps") used to adjust operation.

Most "tuners" have no idea what the code does. They just know how to change the values in the tables. It requires quite a bit of knowledge about how the engine works, but no knowledge of how to program.

I totally agree with you.It's totally different to properly modify a "table-map" and to find this table in memory. Moreover, it's much more difficult to identify it's utility (axis,measurement units etc.). I have used Winols from EVC where you can load a bin file (which was read from the ECU) and search for maps through some KB. I was able to identify via hex code some maps but I am not familiar to do this and it happened accidentally. The problem is that nobody that I have ever asked can guide me properly on this (probably because they didnt have an interest on this section).I am sure that some software engineers and electronic engineers will be able to give some guidance on how these 3-dimension tables are built,where they are stored and how can they be modified/recognized

...like dammos which are all in German and they are a pain in the aas to be understood).

Even if you understand German, the documentation is almost impossible to understand, it is the way it is written, and not everything is even written and published so-to-say. Last year, there was a group that did some reverse-eng in a ECU used by VW, and presented their results at the CCC conference. They didn't know how such a firmware works, but where able to understand quite a bit. I is worth a try to watch the presentation. MISRA C is an abomination, all that stuff should be in the compiler itself, that all of it is an after-thought is just plain bad.

An ECU is nothing more than an application program applied to some kind of processor. The chosen device can be as simple as an old 8051 or as modern as one of the ARM Cortex chips. But the ECU is more than just a CPU, there is some kind of IO interface to convert voltage levels and there may very well be a separate memory chip to contain the tables. If I were designing the box, I would want to put tables in a separate device so that reprogramming of the CPU itself wasn't required. But I don't mess with ECUs...

Embedded programming itself is just a matter of writing code to cause the CPU to perform relatively low level tasks like sensing an input, wiggling an output and keeping time.

In the end, it's all about programming in C. You will need to read thousands of pages of datasheets and 10s of thousands of lines of code to become proficient. You can start with one of the Arduino boards (probably Uno R3) just to get started. Then you can progress to something like the LPC1768 version of the mbed (because it is easy to work with and you don't need to install a toolchain) and move on to the STM32F family or any of the others. It is best to start with something that has a huge fan base so you can copy and paste your projects.

As a Computer Engineer and a gear head who also had the exact same questions years ago- I'll say this, please don't start your embedded systems experience with attempting to reverse engineer ECUs. Look at it this way, once you know how microcontrollers work, you'll then know how ECU's work - not the other way around.

You need a solid foundation to build on, embedded systems involve everything from Computer Science to Electrical Engineering. Don't get caught up on a specific model or manufacturer, and don't start with ARM. You could go the Arduino route but it is highly abstracted and you'll miss out on learning about registers, direct hardware access etc. That's why universities use the Microchip PIC so frequently for their Embedded 1 classes. You get to learn the things you'll need to know in order to program ARM later on.

Towards the end,you won't have nearly as many resources and begin to rely heavily upon just manufacturer's info and data sheets, which can be a real pain in the ass; this is why you need that solid foundation.

It's a long road, but a very rewarding one - you'll have the ability to build complete hardware and software solutions for nearly anything - even ECUs. Good luck and godspeed.

Thank you very much for your reply. I have bachelor on electrical and computer engineering. I am familiar with C++ (not good but I know the basics) so I will continue with C/C++. I luck experience and knowledge on algorithms etc. I have to train on this one. I know how to do circuit analysis and basic to intermediate electronics. So I believe I have to concentrate on C, algorithms and embedded systems analysis.I appreciate your effort to help me with these. All of you guys. Thank you

I have been retired for over 10 years now, but prior to that I work for 30+ years designing automotive powertrain controls, mostly the software, but some hardware also.

First, at least at the company I worked for, there were surprising few "maps". (i.e. z=f(x,y)). the base spark and fuel were based on this but there were a lot of conditional modifiers. Conditional is a very important word because modern piplined processor cores slow down a lot when they "change direction".

Second, because most computer chip companies did not understand how little we used maps (compared to the rest of the application) the focused too much on improving that. Much of this is because (according to my colleagues who are still working) more than 50% of the total EPROM is taken up by monitoring and diagnostic software required by the government.

Last when choosing a processor architecture for an application you must have intimate knowledge of that application. For example, embedded processors designed for digital signal processing typically have a Harvard Architecture. Unlike general purpose chips, the design of memory interface may be optimized in such a way that accessing constants will block the instruction pipeline. Or execution from RAM (for reprogramming) may be painfully slow.

If you really want to deep dive this subject, read the book Computer Architecture: A Quantitative Approach. Now in the 5th edition. My 1st edition is well worn !

An ECU is nothing more than an application program applied to some kind of processor. The chosen device can be as simple as an old 8051 or as modern as one of the ARM Cortex chips. But the ECU is more than just a CPU, there is some kind of IO interface to convert voltage levels and there may very well be a separate memory chip to contain the tables.

Many car manufacturers have a limited list of microcontrollers you can use for certain application and they have to be certified for automotive, CAN bus, memory safety, sometimes lockstep, etc. That's why you see these specific microcontrollers with PowerPC architecture or something else, but not Cortex-M core.

Many car manufacturers have a limited list of microcontrollers you can use for certain application and they have to be certified for automotive, CAN bus, memory safety, sometimes lockstep, etc. That's why you see these specific microcontrollers with PowerPC architecture or something else, but not Cortex-M core.

That topic has been on and off for 20 years in the industry ! I don't know how mush of it ever got implemented. Until recently, the memories did not even have parity let alone ECC.

Bosch and Continental are two of the biggest suppliers in the US and EU industry (Nippon Denso is the king of the Japanese industry but there are othe vendors depending on the Keiretsu they belong to). I am pretty sure their favorite chip is one of the Infeon Tri-Core chips. PowerPC was the hot ticket several years ago with the Motorola (now Freescale) had multiple version all named after Oak trees (Red Oak, White Oak, etc.) Motorola also used to design and assemble ECU but they got out of that business over 15 (?) years ago.

I am not sure what you mean by "lockstep", but every processor architecture I know of use pipelining. The problem with pipelining is "precise" exceptions/interrupts. If an instruction takes more than 1 cycle (and many do, especially floating point instructions) what do you do if you get an external interrupt in the middle of a 10-20 cycle instruction ?

You could "skid" to a stop (continue the instruction in progress but service the interrupt at the end of it) but then the condition code registers and other register may not indicate the store state of the machine when you finally did stop.

Believe or not, most embedded control processors, "rewind". That is, while the processor is working on that multi-cycle instruction, it may have processed 2 or 3 more single cycle instruction. Those are actually UNDONE (previous register values are kept in a register history file).

External interrupt processing is a pain because it takes a large number of cycle to push all of the register on to the stack. There maybe a few multi-cycle instruction where exception processing is locked out.

with "lockstep" he probably means the principle behind the infineon tri-core, multiple cores (in this case three) are excecuting the same instructions in parallel at the same time and the results must be the same, or at least the majority of cores mush agree on the result

Many car manufacturers have a limited list of microcontrollers you can use for certain application and they have to be certified for automotive, CAN bus, memory safety, sometimes lockstep, etc. That's why you see these specific microcontrollers with PowerPC architecture or something else, but not Cortex-M core.

That topic has been on and off for 20 years in the industry ! I don't know how mush of it ever got implemented. Until recently, the memories did not even have parity let alone ECC.

Bosch and Continental are two of the biggest suppliers in the US and EU industry (Nippon Denso is the king of the Japanese industry but there are othe vendors depending on the Keiretsu they belong to). I am pretty sure their favorite chip is one of the Infeon Tri-Core chips. PowerPC was the hot ticket several years ago with the Motorola (now Freescale) had multiple version all named after Oak trees (Red Oak, White Oak, etc.) Motorola also used to design and assemble ECU but they got out of that business over 15 (?) years ago.

I am not sure what you mean by "lockstep", but every processor architecture I know of use pipelining. The problem with pipelining is "precise" exceptions/interrupts. If an instruction takes more than 1 cycle (and many do, especially floating point instructions) what do you do if you get an external interrupt in the middle of a 10-20 cycle instruction ?

You could "skid" to a stop (continue the instruction in progress but service the interrupt at the end of it) but then the condition code registers and other register may not indicate the store state of the machine when you finally did stop.

Believe or not, most embedded control processors, "rewind". That is, while the processor is working on that multi-cycle instruction, it may have processed 2 or 3 more single cycle instruction. Those are actually UNDONE (previous register values are kept in a register history file).

External interrupt processing is a pain because it takes a large number of cycle to push all of the register on to the stack. There maybe a few multi-cycle instruction where exception processing is locked out.

a cortex M4 takes ~12 cycles from interrupt to first isr instruction, they run at several 100MHz so maybe 100ns latency compared to at most a few hundred revolutions be second of an engine that is nothing..

Many car manufacturers have a limited list of microcontrollers you can use for certain application and they have to be certified for automotive, CAN bus, memory safety, sometimes lockstep, etc. That's why you see these specific microcontrollers with PowerPC architecture or something else, but not Cortex-M core.

Bosch and Continental are two of the biggest suppliers in the US and EU industry (Nippon Denso is the king of the Japanese industry but there are othe vendors depending on the Keiretsu they belong to). I am pretty sure their favorite chip is one of the Infeon Tri-Core chips.

It's pretty much only bosch, denso and magneti marelli who bother writing the firmware for ECUs... not many other big players left. They also do all the research.

Those are pretty bold statements.

Quote

I am pretty sure their favorite chip is one of the Infeon Tri-Core chips.

It really depends. The Tri-Core is powerful but it also isn't exactly fun to use from what I hear. It also depends on the history of the particular product (if all previous models used chip X, you don't really want to switch to chip Y and lose all the hard-earned experience) and also the features that are needed and of course the supplier, too. Ever tried getting an eval board for a true automotive MCU from Infineon? Even if you're a big player it can be a real challenge.

a cortex M4 takes ~12 cycles from interrupt to first isr instruction, they run at several 100MHz so maybe 100ns latency compared to at most a few hundred revolutions be second of an engine that is nothing..

12 cycle is impressive ! How do they store the context, including all of the registers ? Or do they just have a second set of registers for processing isr's ?

Some auto manufactures use a 36 toothed wheel on the crankshaft. At 8000 RPM (133 revolution/second) you get 4800 interrupts per second or one every 1.25 msec. A fair amount of number crunching and scheduling of outputs happens every tooth interrupt and you would only have 12,500 cycles.

Of course their are other interrupts that have to be handled, but they are much lower rate.

It's pretty much only bosch, denso and magneti marelli who bother writing the firmware for ECUs... not many other big players left. They also do all the research. And they write it according to the specifics the manufacturer requires

I know at least 1 of the Detroit 3 that still writes at least 90 percent of the code that goes in each ECU. Bosch supplies the rest.

But the ECU is more than just a CPU, there is some kind of IO interface to convert voltage levels and there may very well be a separate memory chip to contain the tables. If I were designing the box, I would want to put tables in a separate device so that reprogramming of the CPU itself wasn't required. But I don't mess with ECUs...

For many years now, the CPU, IO and ALL memory has been on one chip. Moving IO or memory off chip kills performance. This is quite difficult because the IC layout/manufacturing procedures are very different for memory (Flash, RAM) as compared to a CPU. Today's high integrated chips use less than 25% or the silicon for the CPU.