Jump to content
abecedarian

LM3S8962 / LM3S2110 Engine Management System

Recommended Posts

Here's the thread to document the research and development of a vehicle engine management system based on the LM3S8962 Evaluation Kit.

 

Let me preface this by saying, as I am quite new to C programming and microcontrollers this is definitely diving into the deep end of the pool, though perhaps it would be more accurate to relate it to a trip to the depths of the Pacific Ocean.

 

I will also say that I do not expect much feedback from the community with regards to this.

What I mean is that unless you have this kit and are interested in doing the same thing, I do not expect many comments.

But if you see any errors in the coding, PLEASE comment. :D

 

The goals I have set for this are:

  • Provide accurate fuel control over at least 2 banks of injectors, possibly more if the hardware is capable.
  • Provide accurate ignition timing control over engine speeds ranging from a few hundred to over 10000 RPMs.
  • Enable configuration of the system through the built-in display, over CAN and possibly Ethernet.
  • Enable operational error reporting in-situ through the built-in display and CAN, and possibly external fault-LED's or similar.
  • Utilize the main and device boards as efficiently as possible, separating tasks accordingly.
  • Create open-source code free of restrictive licensing: I received the kit for free so this is my way of giving back in kind.
  • Develop open-source hardware interfaces between the EKT boards and the sensors, injectors and ignition components.
  • Come up with a catchy name. StellariSquirt immediately came to mind but is likely too similar to another products name to be used. ;)

I will use the next two posts to identify hardware and software considerations.

 

Thank you.

Share this post


Link to post
Share on other sites

Hardware-

 

Most modern engine sensors operate with a 5v reference provided by the ECU. The other engine components typically operate at 8-15 volts.

Sensor power will require accurate regulation and ground returns, as well as isolation and possibly filtering to prevent any noise on the wires.

Any interface between the engine components and the ECU will need to be buffered / isolated to prevent damage to the ECU.

 

Common sensors required for engine operation:

  • Throttle position sensor (TPS): typically a linear potentiometer; used to calculate air mass when coupled with a manifold absolute pressure sensor, and to determine engine loading.
  • Manifold absolute pressure (MAP): senses engine vacuum and pressure (super/turbocharged engines); used in calculations of air flow and fuel injection quantity, as well as to establish barometric pressure, which is used to more accurately predict aif flow. Some vehicles may have two: one for manifold pressure and a second for barometric pressure.
  • Mass air-flow: typically a heated-wire used to determine the mass of air entering the engine. May be used in conjunction with, or as an alternative to, a MAP sensor.
  • Coolant temperature: used to determine fuel injection quantity primarily during cold engine operation. Can also be used to affect timing.
  • Intake air temperature: used in conjunction with MAP sensor to determine intake air mass.
  • Crankshaft sensors: may be optical, hall effect or variable-reluctance type; used to determine crankshaft speed and position primarily for ignition timing purposes.
  • Camshaft sensors: there may be multiple sensors and they may be optical, hall effect, variable reluctance or physical contact "points". Their usage includes: synchronizing fuel injection events with engine intake events; identifying the engine "stroke" and triggering ignition events; more accurate calculation of crankshaft position.
  • Lamda / Oxygen sensors:
    • Narrow-band (aka, the common O2) sensor- designed to provide an output voltage between 0v and 1v, though roughly 0.5v when the exhaust O2 content reflects stoichiometric fuel ratio. ECU's using these typically cycle the fuel mixture between slightly rich to slightly lean based on feedback from this type sensor. They also typically stop monitoring this sensor under high engine loading, i.e. throttle open more than 70-75% and fall back to pre-programmed "rich" values to aid in power... side note: this "rich" running is what causes that rotten egg smell from catalytic converters.
    • Wide-band O2- provides a range of output voltage roughly equivalent to the actual oxygen content of the exhaust. Very useful for tuners looking to get reliable peak power output. Also highly valuable for people with super/turbocharged engines who want to target a specific air/fuel ratio to help prevent detonation.

    [*]Knock sensors: In a world full of perfect, we wouldn't need them, but they will signal when the mixture is too lean or the timing is too advanced. Unfortunately, they are not reliable at high-rpms... and how to deal with "knock" is a subject of debates: retard the timing or inject more fuel? Personally, I'd probably add fuel, but others will likely disagree.

Feel free to comment.

Share this post


Link to post
Share on other sites

Software-

 

Prioritizing the sensors....

Some of the sensors mentioned above are comparatively slow to update: coolant temp for instance.

Others may vary between relatively consistant to rapidly changing over a period of time: TPS, MAP and wide-band O2 for instance.

Crankshaft and camshaft sensors won't change unless the engine is accelerating or decelerating.

 

I see we can:

  • Use a simple loop and timer: sample all the sensors as often as possible, calculating the necessary variables and triggering events.
  • Use interrupts to generate events based on the engine state.

With my motorcycle, the latter is probably the better choice since I have 2 crank sensors and 2 cam sensors, I could generate interrupts when those sensors are triggered: when a cam event triggers, I could sample the relavent sensors, calc fuel and inject; when a crank event occurs, I could instantiate a timer that fires a spark plug at the correct time.

 

However, I don't believe that is optimal for a "universal" ECU. More likely, it would be a combination of the two, where sensors are sampled repeatedly and interrupts, whether crankshaft, camshaft or timer derived cause events to occur.

 

There is also the issue of determining how much fuel, timing, etc is needed. Typically, the user would input a "volumetric efficiency" table for the engine based on the approximate fuel requirments of the engine indexed to RPM and Load (MAP & TPS based. Alternatively, a table of target AFR (air/fuel ratio) for any given MAP / TPS position could be supplied. Whichever is used, they require an array of values be input or learned by the ECU. The benefits of "table based" calculations means faster response time since it is quicker to retrieve a value from RAM and apply some corrections than it is to sample sensors and perform calculations on those values. However, a processor dedicated to certain tasks, passing values to another processor for final operations is a win-win, no?

 

Hence, I feel dedicating the LM3S8962 main board to sampling sensors and providing the configuration interface to the user, while passing many of the variables over CAN to the LM3S2110 device board for final calcs and triggering injection and ignition is a viable solution.

 

 

Feel free to comment.

Share this post


Link to post
Share on other sites

I have attempted contact with the open5xxxECU project: http://code.google.com/p/open5xxxecu/

... with the intent of informing them what I intend to do, and my willingness to contribute any changes we require to a branch of their code-tree.

 

Their software is licensed:

Part of the Open5xxxECU project. open5xxxecu.org

See the o5e directory for code.

Copyright © 2011

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

 

This appears to be one of the least restrictive license terms I've seen.

Share this post


Link to post
Share on other sites

I'm a little torn between writing the crank/cam decoder to satisfy my requirements, implementing a system where other users could write their own crank/cam decorders in C and compile it in, or providing a generic system where the cam/crank sensor information is input during configuration and the system adapts a la current, off-the-shelf systems.

Share this post


Link to post
Share on other sites

I imagine a GUI could be created which would be able to interface with the system over CAN or Ethernet (since the main board supports those), or would have a "configuration wizard" and store tables on microSD which would be inserted to the mainboard.

 

I'm just thinking about what the EKT provides and finding ways to use those.

Share this post


Link to post
Share on other sites

Feel free to comment.

 

 

Another thing to consider is the impedance of the fuel injectors. There are "high" and "low" impedance injectors. The high impedance injectors basically require constant volts and amps applied to hold them open whilst the low impedance units draw a few amps to open and require much less amps to keep them open. It's a little more complicated than that but... the net result is low-z injectors open and close faster than high-z units. Low-z injectors can be dealt with on a high-z system with either inline resistors or PWM. I don't know if I want to go there with the code though. Have to check the datasheets to see if that is possible. One of the goals was to support 2 banks of fuel injectors. PWM injectors would probably requrie external drivers.

 

I will caution though that low-z injectors may appear paneceae- open and close fast means more accurate fuel delivery, but they are not because of the more expensive hardware or complicated software needed to support them. Often, the benefits of low-z injectors can be mitigated by staging injectors: lower flowing injectors below X rpm, and higher flowing injectors triggered above X rpm: known as staged injection, albeit at higher costs.

Share this post


Link to post
Share on other sites

I mentioned it in my blog, I think, but it bears mentioning here:

open5xxxecu is using cocoos as a RTOS in their system.

 

I understand the reasoning for an RTOS in the system, but question the necessity.

If interrupts are handled properly and exit correctly, is a watchdog necessary?

Share this post


Link to post
Share on other sites

I understand the reasoning for an RTOS in the system, but question the necessity.

If interrupts are handled properly and exit correctly, is a watchdog necessary?

 

RTOS is not necessary. If you handle interrupt priorities well, you should be good.

Watchdog is used for sensing if a ,microcontroller has "hung". If the watchdog hardware does not get its interrupt serviced by the software, it can trigger a reset or implement safety protocols.

 

If you are new to C, this project will be a handful. Try doing simple stuff like button interrupts/leds and then low level comm - rs232, spi and then CAN.

Share this post


Link to post
Share on other sites

RTOS is not necessary. If you handle interrupt priorities well, you should be good.

Watchdog is used for sensing if a ,microcontroller has "hung". If the watchdog hardware does not get its interrupt serviced by the software, it can trigger a reset or implement safety protocols.

 

If you are new to C, this project will be a handful. Try doing simple stuff like button interrupts/leds and then low level comm - rs232, spi and then CAN.

Thank you for the input and I know it will be a handful. That's why I mentioned "...it would be more accurate to relate it to a trip to the depths of the Pacific Ocean."

 

I'm thinking I can use the MSP430's here to simulate inputs to the "ECU" controller. If you are familiar with Megasquirt, the JimStim http://jbperf.com/JimStim/index.html is what I'm thinking of. But that's another thread though. ;)

 

I will admit, most of the code I need has been written; porting that from one architecture to another is going to be the bear

Share this post


Link to post
Share on other sites

With regards to separating tasks between the main board and device board....

 

I think I will have the main board sample most of the sensors, as in the analog ones, since it has ADC and the device board doesn't; and the device board will be responsible for triggering ignition coils and injectors.

 

If I can keep their clocks synchronized, the above shouldn't be a problem. Let the main board sample sensors and pass values for the injectors to the device board.

The device board can process ignition (digitally triggered) events (since it lacks ADC) and work with that to calculate ignition timing and fire coils.

 

*- disclaimer- this is still in the discussionary stage and no functional hardware has been developed.

Share this post


Link to post
Share on other sites

Specific to my motorcycle:

  • Turbocharged V-twin, 80 degree included angle, single "throw" crankshaft.
  • Ignition and injection are controlled by two, separate control units.
  • Single tooth crankshaft flywheel "trigger". Tooth is "advanced" ~24 degrees in relation to the throw on the crankshaft.
  • 2 crankshaft "VR" sensors, left cylinder sensor mounted 80 degrees from the right cylinder, which mirrors the physical cylinder separation, connected to the "ignition" computer.
  • 1 MAP sensor, sensing vacuum & pressure from the intake manifold, connected to the ignition computer. It's signal is used to advance / retard timing in relation to turbo boost.
  • 2 camshaft "VR" sensors, left cylinder sensor mounted 160 degrees from the right cylinder, connected to the EFI computer, used to calculate engine speed and time fuel injection.
  • 1 intake air temperature sensor mounted immediately after the air filter
  • 1 coolant temperature sensor mounted at the the thermostat housing
  • 3 MAP sensors connected to the EFI computer, which are used for various purposes:
    • one is connected to the intake immediately after the air filter and senses atmospheric pressure only;
    • the next is connected to the intake manifold- it senses vacuum only and becomes saturated and thus useless under boost;
    • the last is connected to the intake between the turbo and the throttle and is used to sense boost

 

Though the system works well... 82 horsepower (60.31 kW) from a ~500cc engine (97hp from its successor, the CX650T) is nothing to sneeze at, and gives any other v-2 and many 4 cyl motorcycles a pause for thought... the complexity of this system and the way it operates is part of the reason why I want to change it. The other reason is the scarcity of replacment parts: this motorcycle (CX500TC) was only produced one year- 1982 with around 5000-6000 built, and it's successor, the CX650T was only available in 1983 with even fewer units made for sale. The 650 also had a different configuration of the electronics which dropped the ignition system's MAP sensor and rolled some of that function into the EFI computer. For those into facts: the CX500TC and CX650T engine control units were the initial steps into Honda's later PGM-FI system used on the later EFI cars and motorcycles; Honda didn't go through the analog fuel injection stage most other car makers did. But I digress....

 

 

The ignition system is two-channel, which separates the left and right cylinders' ignition events. It uses the two VR sensors and MAP sensor mentioned above and two ignition coils, one per cylinder, and fires each coil once per engine revolution. This is known as wasted spark operation and is generally harmless to an engine: the intake valve is rarely open when the 2nd spark occurs so therefore, there is no significant air / fuel mixture in the cylinder when the plug fires. The MAP sensor connected to the ignition unit provides a signal used to advance or retard timing according to manifold vacuum or pressure, respectively. At high vacuum, ignition is advanced to as much as 45 degrees, at 0 vacuum timing is 25 degreees, and generally retards one degree per PSI of manifold pressure when under boost. And that's pretty much it. There's no other compensation involved

 

The fuel injection system is even more complicated. 3 separate MAP sensors is 1, maybe even 2, more than required considering modern electronics. Additionally, Honda apparently didn't anticipate, and thus didn't program for, the system being used at high elevations. It becomes confused and throws errors when the bike is started at low elevations and runs up to high elevations. Anyhow, the system operates with a speed/density algorithm when not under boost, and transitions to a programmed fuel map with rpm and boost used to grab values from a table. There is some compensation for coolant and ambient air temps, but, no compensation for the "charge" air temperature (compressing air raises its temperature). Though it worked, it was obviously limited by the electronics of the time, and programmed to use "safe" values: leaner fuel mixtures could have made more power, but without things like knock sensing and calculating air mass based on the actual "after the turbocharger" intake air temperature, they had to err on the side of caution else be presented with warranty claims.

 

 

 

Anyhow, there is my argument for abstraction. I could build the unit to work on my motorcycle, but it would be mostly useless for anyone else.

 

The downside is code-bloat, where the code would require multiple variables be set for it to work properly. But that may be required to make this general-purpose. The alternative is to make it modular, where the user writes her/his own routines to handle their hardware, and compiles it into the runtime.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×