LM3S8962 _ LM3S2110 Engine Management System - Projects - Tiva-C ARM Community Forums

Ngày 5 tháng 9 năm 2014 LM3S8962 / LM3S2110 Engine Management System - Projects - Tiva-C ARM Community Forums

http://forum.stellarisiti.com/topic/270-lm3s8962-lm3s2110-engine-management-system/ 1/9

Tiv a -C A RM Com m u n ity For u m s → Stella r is A RM Tech n ica l For u m s → Pr ojects

Pa ge 1 of 3

LM3S8962 / LM3S2110 Engine Management SystemStarted by abecedarian , Oct 06 201 2 1 1 :52 PM

EKT-LM3S8962, EFI,

abecedarian

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.

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.

Posted 06 October 2 01 2 - 1 1 :5 2 PM

abecedarian

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


http://forum.stellarisiti.com/

http://forum.stellarisiti.com/forum/33-stellaris-arm-technical-forums/

http://forum.stellarisiti.com/forum/35-projects/

http://forum.stellarisiti.com/tags/forums/EKT-LM3S8962/

http://forum.stellarisiti.com/tags/forums/EFI/



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.

abecedarian

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.


abecedarian

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

(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:

Quote

Part of the Open5xxxECU project. open5xxxecu.org

See the o5e directory for code.

Copy right © 201 1

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 abov e copy right 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.

Posted 07 October 2 01 2 - 01 :3 9 A M

abecedarian

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.


abecedarian

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.


abecedarianPosted 07 October 2 01 2 - 02 :07 A M

http://code.google.com/p/open5xxxecu/



'abecedarian', on 07 Oct 2012 - 06:52 AM, said:


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.

abecedarian

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?


bluehash

'abecedarian', on 07 Oct 2012 - 09:18 AM, said:

I understand the reasoning for an RTOS in the sy stem, 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.


abecedarian

'bluehash', on 07 Oct 2012 - 09:48 AM, said:

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

Watchdog is used for sensing if a ,microcontroller has "hung". If the watchdog hardware does not get its interrupt serv iced

by the software, it can trigger a reset or implement safety protocols.

If y ou are new to C, this project will be a handful. Try doing simple stuff like button interrupts/leds and then low lev el

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 (http://jbperf.com/JimStim/index.html) is what

I'm thinking of. But that's another thread though.


http://jbperf.com/JimStim/index.html



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

abecedarian

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.


abecedarian

Source for the current, as of Oct 06, open5xxxECU project is here: http://open5xxxecu.g...ark2012Jul1.zip

(http://open5xxxecu.googlecode.com/files/open5xxxecuMark2012Jul1.zip)

I worry it has had no movement since July....


abecedarian

I'm a little worried about things since the open5xxxecu project is linked to MSqorivva... which is linked to

megasquirt....

Posted 07 October 2 01 2 - 04 :07 A M

abecedarian

Maybe there should be an "engine abstraction layer" where the user chooses their sensor arrangement and the code

adapts?


abecedarian

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

Posted 07 October 2 01 2 - 04 :1 6 PM

http://open5xxxecu.googlecode.com/files/open5xxxecuMark2012Jul1.zip



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.

abecedarian

To be general purpose, there are issues which must be addressed in the hardware interface and software

interpretation of the sensors and triggers.

Sensors:

Obviously, we would like to re-use any sensors the vehicle provides. So code would need a way to support those. In

addition, providing parameters to support common, off-the-shelf sensors could be provided, correct? For instance

provide in-built support for various manufacturer's air, coolant and MAP sensors?

Triggers:

Obviously (again), support for different crank and cam triggers / pick-ups would be required.

See why I'm also looking at existing projects for this?




I am leaning towards being modular in the implementation, but not all-inclusive. I've already enough to do trying to

figure out a basic system to run my motorcycle without the added overhead of figuring out how to run everyone

else's engine.

abecedarian

Divide and conquer

*work in progress*

LM3S8962 board:

Idle state is lowest power mode, waiting for a signal to indicate the key has been turned on.

Power on:

Bring all inputs and outputs up is a safe state.

Power fuel pump on for 3 seconds to prime injection.

Sample TPS, coolant and air temperature sensors, and MAP (and barometric sensor if installed).

Determine if cold-start enrichment is needed and calculate amount based on coolant temp.

Calculate ambient air density from initial MAP (or baro) and standard constants.

Check for button press on device indicating user wants to modify settings prior to starting the engine:

If button is pressed within 5 seconds of power on means user wants to adjust something so provide GUI for

setup and tuning via on-board buttons and oled:

Check for uSD card. If card is present, read and compare configuration settings to flash-stored data.

If SD == flash, assume flash has current settings. Send relevant settings to LM3S2110 device

board.

If SD != flash, prompt user via on-board oled to choose:

A.) Import SD data and back-up Flash internally or to SD. Ask if user wants automatically

discard Flash backup the next time the ignition is turned off.

If the user chose "Yes", SD contents are committed automatically, Flash back-up is

deleted, unit powers down when the key is turned off.

If user chose "No", device will wait 5 minutes for a key press before turning off.

If a key is pressed, display will wake and prompt to keep or discard settings

imported from SD.

If user chooses "Keep", remove Flash backup from SD card and power

down the unit.

If user chooses "Discard", Flash backup is restored then deleted from

SD and the unit powers down.

B.) Cancel.

Starting the engine:

Receives input indicating "Start" button was pressed (button does not need to be held down).

Apply power to O2 sensor. (If used- I'm still undecided).

Turn on fuel pump.

Beep 5 times, indicating preparing to start.

Begin sampling sensors:

- TPS, MAP and intake air temp as often as practicable, should be at least ??? times per second

- Coolant temperature and O2 (if installed): at least ??? times per second

Calculate desired fuel injector pulse width and send to device board.

Turn on starter relay.

Receive RPMs from device board:

If RPM's are sufficient to indicate the engine is running:

Turn off starter relay.

Enter normal running mode.

If within 5 seconds, RPMs aren't sufficient to indicate engine is running:

Turn off fuel pump.

Turn off starter relay.

Request from device board:

Last ignition timing setting (should be roughly constant until engine is within 15% or target idle




speed)

Intervals between last 8 consecutive crank trigger events.

Intervals between last 4 consecutive cam trigger events.

{Any other variables I might later think to include.}

Send signal to device board to put all outputs in a safe state.

Beep the speaker and display on screen (scrolling) for 5 minutes:

Intake air and coolant temps.

MAP and TPS measurements.

Air/fuel ratio target.

Last RPM reading from device board.

Last crank and cam intervals.

{Any other variables I might later think to include.}

Power down and do not permit re-starting until key has been turned off.

Power down procedure:

Put all inputs and outputs in a safe state.

Send request to device board to put all inputs and outputs in a safe state.

Go through "save data" procedures mentioned above if necessary.

Power down.

LM3S2110:

Idle state is lowest power mode, waiting for a signal to indicate the key has been turned on.

receives general fuel requirements as calculated by the main board

accepts Interrupts generated by crankshaft and camshaft events

calculates engine RPM

calculates ignition timing and fuel injection timing

triggers ignition and injection events

*still work in progress*

Edited by abecedarian, 09 October 2012 - 01:40 AM.

Stellarisiti

You have been busy this weekend.


abecedarian

'Stellarisiti', on 08 Oct 2012 - 02:38 AM, said:

You hav e been busy this weekend.

I agree.

But then, I do often ramble a lot before I start producing results.

A former "boss" used to get mad because I would stand around, looking around for an hour or more even, before I

began work.

But he was hard-pressed to find any faults with the work I did afterwards.

The addage is: "measure twice, cut once". The implication is planning ahead and verifying what was done follows the

plans seldom results in failure.

Did I mention the plan I have for using an MSP430G2553 as a state machine in order to simulate the motorcycle for




Pa ge 1 of 3 Back to Projects · Next Unread Topic →

Tiv a -C A RM Com m u n ity For u m s → Stella r is A RM Tech n ica l For u m s → Pr ojects

use to feed back triggers and such to this?

abecedarian

I suppose I should say that although it appears I've posted a lot in a short period...

... a lot of that has been stewing in my mind.



http://forum.stellarisiti.com/topic/270-lm3s8962-lm3s2110-engine-management-system/?view=getnextunread

http://forum.stellarisiti.com/

http://forum.stellarisiti.com/forum/33-stellaris-arm-technical-forums/


Documents

LM3S8962 _ LM3S2110 Engine Management System - Projects - Tiva-C ARM Community Forums