--- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@...> wrote:
> I'm pretty sure it's not a rumor. At WOT and idle the ECU bypasses few
> calculation stages and does not read AFM. That's why you always
> have three maps: idle, WOT, middle load. Same for start-up.
> Just try to start your engine with a disconnected AFM, it will work.
> Alexis
>

Hi Alexis.

This was my understanding too. But the code does not fit to this theory. I'm looking into ML3.1 944 Turbo code.

The ADC is called in the main loop regardless the actual mode. It then calculates the basic injection time. This is limited to a minimum and maximum value. That may be the reason, the engine starts without a AFM.

The tables you are mentioning are correction factors to this base value with the same unit/function like the FQS enrichment factors.

>
> After all - this shows that the AFM signal is always used to calculate the
injection time. The rumors that the AFM signal is not used in  injection
calculation at full throttle are not correct.

I'm pretty sure it's not a rumor. At WOT and idle the ECU bypasses few
calculation stages and does not read AFM. That's why you always
have three maps: idle, WOT, middle load. Same for start-up.
Just try to start your engine with a disconnected AFM, it will work.
Alexis

>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
> .
>

Glad it helped :)
Where is the final corrected time value?
And which ADC read are you referring to?

-Joshua


----- Original Message ----
From: T_Voigt <t_voigt@...>
To: BoschDME@yahoogroups.com
Sent: Thu, November 19, 2009 1:29:23 AM
Subject: [BoschDME] Re: The meaning of engine load?

> Also take a look at this post made by TT.  Load is something I've been meaning
to look into.
> This post has the basics of how load is calculated:
>
> http://forums.rennlist.com/rennforums/472327-post18.html
>
>
>
> -Joshua

Hi Joshua. Thanks for this link. It describes the code I'm currently looking at.
This guy TT was here before. Respect.

It looks like there is a basic injection time value calculated everytime the ADC
is read. Then this value is corrected by the result from several tables. All the
injection tables we're normally dealing with do have the unit [+/-%] with 128
for 100%. The corrected time value is then set to Timer 0 to control the
injection valves.

Great help - thanks!

Thomas




------------------------------------

Yahoo! Groups Links

This is very close to what was published in a 1977 technical paper by Bosch.

The key item is that the Base Time is an injector flow coef.  Possibly mg/msec
or grams/sec time base being pulse width.  I am theroizing this.... but I have a
strong feeling it is true.

I will try to scan that article and post it with the proper reference to the
Bosch authors.


Mike D.

--- In BoschDME@yahoogroups.com, "T_Voigt" <t_voigt@...> wrote:
>
> So load is a short value of BTi (base injection time) with the unit time
>
> Load = BTi/25
>
> The final injection time Ti is:
>
> Ti = (BTi * AdjustmentFactors) + VoltageCorrection
>
> After all - this shows that the AFM signal is always used to calculate the
injection time. The rumors that the AFM signal is not used in  injection
calculation at full throttle are not correct.
>

Thank you very much Tom.   This gives me a starting point.

Mike D.

> Hello Mike.
>
> Sorry for the late answer - I wasn't online for a while...
>
> Yes - I used the MPX4250 sensor as replacement. I also had to adjust all three
PID constants since the original setup tends to swing at higher presure. The
mapping is easy. Two maps are responsible for boost control. A startvalue table
for CV frequency at 0B00 and a target pressure table at 0C00. The PID starts
controlling the CV with the startvalue and corrects it until the target boost is
reached.
>
> Thomas
>

So load is a short value of BTi (base injection time) with the unit time

Load = BTi/25

The final injection time Ti is:

Ti = (BTi * AdjustmentFactors) + VoltageCorrection

After all - this shows that the AFM signal is always used to calculate the
injection time. The rumors that the AFM signal is not used in  injection
calculation at full throttle are not correct.

Thanks for your help. I wasn't sure if this command is a hidden secret in the
8051 world...

> 1. I'd have to see the bigger picture to be more certain, but this could be
executable code.  This is important.  What comes before and after this code?

It is a subroutine that is used to add A to B and store the sum in B. It is
called several times to sum up different parameters in B. This editor destroys
formating - but this is the complete code:

AddB2toAcB:
        ADD     A,B             ; add A to B
        JNC     laExit          ; check Carry

        MOV     A,0FFH          ; ???

laExit: MOV     B,A            ; store sum in B
        RET

> 2. The original author intended for this to be MOV A, #FFh, however, he or she
made a syntax error.
>
> ie. the code says if there is an overflow when A & B are added, then make A
the maximum value of an 8-bit number.
>
> 3. The resulting syntax error actually produces the same numerical result
during program execution.  Although the author didn't intend to read from the
SFR, the result is the same in that A get #0FFh.
> Because the program worked as he expected, he never caught his syntax error.

I aggree on that. I tried with several simulators the code and A was allways
filled with FF.

Thanks again for your help!

Thomas

It's SFR space.
For a 8051 and 8052, 0FFh is not defined.

MOV A, 0FFh
This instruction would not be illegal, is not good practice.
One should not read or write to unused SFRs as this makes the code incompatible
with CPU changes should those SFRs be later implemented.
I don't remember for sure, but I think it might return 0xFF for an unused SFR.

Also, if you dissemble binaries, not all data is code.
The data you disassembled could be unused space, misc data, a map, etc.
Forcing the disassembly of such information essentially produces gibberish.
When I see things that don't make sense, it's often a signal that the portion of
binary I'm looking at should not be interpreted as code.

However, the code below would make a lot of sense if it was:
   ADD A,B
   JNC xlable
   MOV A,#0FFH
xlable:
   MOV B,A

Also, the code does appear to be sensible and intentional otherwise, so, my
guess is as follows:

1. I'd have to see the bigger picture to be more certain, but this could be
executable code.  This is important.  What comes before and after this code?

2. The original author intended for this to be MOV A, #FFh, however, he or she
made a syntax error.

ie. the code says if there is an overflow when A & B are added, then make A the
maximum value of an 8-bit number.

3. The resulting syntax error actually produces the same numerical result during
program execution.  Although the author didn't intend to read from the SFR, the
result is the same in that A get #0FFh.
Because the program worked as he expected, he never caught his syntax error.


--- In BoschDME@yahoogroups.com, "T_Voigt" <t_voigt@...> wrote:
>
> Can someone look at this code?
>
> ADD A,B  ; 0a55   25 f0      %p
> JNC xlable  ; 0a57   50 02      P.
> MOV A,0FFH  ; 0a59   e5 ff      e.
> xlable: MOV B,A ; 0a5b   f5 f0      up
>
> From my understanding it adds B to A. If the carry bit is set it loads A with
the content of FFH. This is not used anywhere else. Is FFH the RAM address or a
SFR? What does this mean?
>
> It is code from a ML3.1 box.
>

Can someone look at this code?

ADD A,B  ; 0a55   25 f0      %p
JNC xlable  ; 0a57   50 02      P.
MOV A,0FFH  ; 0a59   e5 ff      e.
xlable: MOV B,A ; 0a5b   f5 f0      up

From my understanding it adds B to A. If the carry bit is set it loads A with
the content of FFH. This is not used anywhere else. Is FFH the RAM address or a
SFR? What does this mean?

It is code from a ML3.1 box.

Hi,

I'm new in the chip tuning, and I'm trying change the rev limiter of a chip of
my Citroen AX GTi, the actual rev limiter is to elevated (8100) I think...

And I'cant find the rev limiter in the bin file! cam anyone help me please?

Thanks

Joćo

> Also take a look at this post made by TT.  Load is something I've been meaning
to look into.
> This post has the basics of how load is calculated:
>
> http://forums.rennlist.com/rennforums/472327-post18.html
>
>
>
> -Joshua

Hi Joshua. Thanks for this link. It describes the code I'm currently looking at.
This guy TT was here before. Respect.

It looks like there is a basic injection time value calculated everytime the ADC
is read. Then this value is corrected by the result from several tables. All the
injection tables we're normally dealing with do have the unit [+/-%] with 128
for 100%. The corrected time value is then set to Timer 0 to control the
injection valves.

Great help - thanks!

Thomas

IIRC, the AFM curve is a function from the three AFM tables:

T1 x T3 x 2^T2


Also take a look at this post made by TT.  Load is something I've been meaning
to look into.
This post has the basics of how load is calculated:

http://forums.rennlist.com/rennforums/472327-post18.html



-Joshua



----- Original Message ----
From: T_Voigt <t_voigt@...>
To: BoschDME@yahoogroups.com
Sent: Wed, November 18, 2009 12:01:30 PM
Subject: [BoschDME] Re: The meaning of engine load?

--- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@...> wrote:
>
> Basically it's the amount of air in grams entering each cylinder per cycle.
> To get it Motronic takes the flow, gets the volumetric flow, corrects it
> with air temperature and pressure and divides by number of cyls and RPM.
> Hope I'm not wrong, I still can not find out my notes with ML3.1 disassm.
> Alexis

Yep. Thanks for the response. I'm sitting in front of the code calculating the
load value. The AFM curve is scaled strangely. A lot of questions are open. The
only way is to go step by step through this code...

I'm building an external interface to the DME/cable connector to calculate the
table parameters from the sensor input values. My goal is to get the actual
parameters in real time into my computer to see which tabel cells are read in
certain situations.



------------------------------------

Yahoo! Groups Links

--- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@...> wrote:
>
> Basically it's the amount of air in grams entering each cylinder per cycle.
> To get it Motronic takes the flow, gets the volumetric flow, corrects it
> with air temperature and pressure and divides by number of cyls and RPM.
> Hope I'm not wrong, I still can not find out my notes with ML3.1 disassm.
> Alexis

Yep. Thanks for the response. I'm sitting in front of the code calculating the
load value. The AFM curve is scaled strangely. A lot of questions are open. The
only way is to go step by step through this code...

I'm building an external interface to the DME/cable connector to calculate the
table parameters from the sensor input values. My goal is to get the actual
parameters in real time into my computer to see which tabel cells are read in
certain situations.

Hi Christian,
Which Harris chip do you think of ?

Christian wrote:
> I see. I think I also have a Motronic 3.1 somewhere. It's the ecu from the E36
BMW I believe. I actually took the M1.3 because I thought it would be easier to
start with. If you have some of your old notes left somewhere it would be very
welcome. This big I/O chip is the one from Harris as far as I can see. But maybe
I'm wrong.
>
> Regards,
> Chris
>
> --- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@...> wrote:
>> The BMW m1.3 already has this huge I/O component with
>> 3 x 8bit ports and some other stuff.
>> Unfortunately when I disassembled the ML3.1 I wrote all my notes
>> on the paper.
>> Alexis
>>
>> Christian wrote:
>>> BMW 320i E30 for the motronic m1.3
>>> Opel kadett GSI 16V for the motronic 2.5
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>>
>>> --- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@> wrote:
>>>> What car does your M1.3 come from ?
>>>>
>>>> Christian wrote:
>>>>> Hi Alexis,
>>>>>
>>>>> In the beginning I was looking to the motronic 2.5. After a while I found
a schematic and disassembled files here in this NG of the M1.3. So I started
using these. This evening I will have a look again if I'm able to recognize some
of the basic routines. It would be helpfull if maybe somebody already did some
of this reverse engineering and is willing to share this information with other
people who are interested in this kind of technology of the past.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@> wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> I spent some time on that. I did not go up to the end, I just wanted
>>>>>> to know how everything works to be able to rewrite the firmware.
>>>>>>
>>>>>> Other guys went much farther, you'll find some files in the file
>>>>>> section of this NG and the alfa75 group.
>>>>>> The tooth decoding is the most complicated processing in Motronic,
>>>>>> it's very complicated and this is what limits the max rev that
>>>>>> ECU can support.
>>>>>> What Motronic are you talking about ?
>>>>>> The custom chips usually contain I/O ports and analog logic,
>>>>>> everything is done by the CPU.
>>>>>> Late 8bit ECUs like those in BMW 6IL sequential had a huge custom
>>>>>> chip which contained I/Os, some memory and possibly timers. The
>>>>>> datasheet of this thing is unknown, unfortunately. These ECUs are the
>>>>>> most interesting when trying to rewrite the code as they have
>>>>>> lots of I/Os.
>>>>>>
>>>>>> Ignition dwell is a table look up procedure with lots of tables accessed
>>>>>> one after other. Actually everything is calculated through tables,
>>>>>> with a little exception for the "load" which is used as an input
>>>>>> parameter of many tables.
>>>>>>
>>>>>> Alexis
>>>>>>
>>>>>> Christian wrote:
>>>>>>> Hello Alexis,
>>>>>>>
>>>>>>> Thanks for the answer. I've already been looking a little to the
assembly code and ofcourse some more questions raise. How do they determine
dwell? Do they use lookup tables? Are the bosch custom asics 30015 or 30106
involved in the missing tooth or ignition proces? I also was wondering if
somebody already did some reverse engineering on these kind of things in the
past.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> --- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@> wrote:
>>>>>>>> Hi,
>>>>>>>> I believe it triggers on the falling edge.
>>>>>>>> It counts every tooth and compares the length of the previous and the
>>>>>>>> new tooth. If there is a difference of 2 then it's the ref tooth.
>>>>>>>> The virtual number of 60 teeth is divided by the number of cyl/2
>>>>>>>> in order to know the current phase. Then the ignition instant is
>>>>>>>> programmed with a timer from a reference position of each phase.
>>>>>>>> The injection is batch fire, it's started at some instant every
>>>>>>>> revolution.
>>>>>>>> Alexis
>>>>>>>>
>>>>>>>> Christian wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> I was wondering if somebody knows how the trigger wheel decoding
algorithm works inside the older motronic ecus. I believe they trigger on both
edges of each tooth. Do they use some sort of angle counter?
>>>>>>>>> Maybe somebody has a more detailed explanation. I will also have a
look at the assembly source code which I've found in the Files section of this
group. Thanks in advance.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------
>>>>>>>>>
>>>>>>>>> Yahoo! Groups Links
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>> Yahoo! Groups Links
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------
>>>>>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>> .
>>>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>> .
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
> .
>

Basically it's the amount of air in grams entering each cylinder per cycle.
To get it Motronic takes the flow, gets the volumetric flow, corrects it
with air temperature and pressure and divides by number of cyls and RPM.
Hope I'm not wrong, I still can not find out my notes with ML3.1 disassm.
Alexis

T_Voigt wrote:
> There is one parameter in the motronic tables, I'm still not finally finished
with: the engine load parameter.
>
> How is it calculated and what unit would represent it best? Normally most
editors look at it as a percentage value (0-255 -> 0-100%). But percentage of
what? And what's the unit of this 'what'?
>
> Any thoughts are welcome... ;-)
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
> .
>

There is one parameter in the motronic tables, I'm still not finally finished
with: the engine load parameter.

How is it calculated and what unit would represent it best? Normally most
editors look at it as a percentage value (0-255 -> 0-100%). But percentage of
what? And what's the unit of this 'what'?

Any thoughts are welcome... ;-)

> So Tom, did you put one of the freescale MPX4250 sensor inplace of the old
clunky sensor??
>
> So did you rework the code or just the PID constants??
>
> Care to share any mapping info?  I have some time scheduled this fall to dyno
a 951.  The first pass with the welti KLR chip looked good at the track.  The
DME chip was using the Atlantis Consulting Hack.
>
> Mike D.

Hello Mike.

Sorry for the late answer - I wasn't online for a while...

Yes - I used the MPX4250 sensor as replacement. I also had to adjust all three
PID constants since the original setup tends to swing at higher presure. The
mapping is easy. Two maps are responsible for boost control. A startvalue table
for CV frequency at 0B00 and a target pressure table at 0C00. The PID starts
controlling the CV with the startvalue and corrects it until the target boost is
reached.

Thomas

Hi,

With your inputs I found where the checksum is calculated.

It's at 31BD

Try to replace the code at 31BD with the following 8 bytes:

   [75 6F 1E] MOV 6Fh, #1Eh
   [C2 D5] CLR F0
   [02 31 F1] LJMP 31F1

This should make think Motronic the checksum is OK

Alexis


FR wrote:
> The Checksum from 0000h to 5EFFh is
> 7EA4h
>
> Stored at 5F00h-5F01h
> 7EA4
>
>
>
> --- In BoschDME@yahoogroups.com, Ville Granfors <ville.granfors@...> wrote:
>> Do you mean that if some value is upped some amount stuff bytes should be
>> lowered same amount?
>> Maby that is the reason why there is some FF turned to 00 in those binaries
>> that I'm comparing.
>> These files are now in files section. Binaries others, opel_motronic_543.zip
>> This file contains original and  modified binary.
>> From these files I can calculate checksum with hex workshop for area 2000 to
>> 5f00 and it matches for value in 5f01, but if I make changes to binary and
>> calculate new checksum for same area, check engine ligth is illuminated.
>> Thats why I was thinking that there is another checksum, but maby there is
>> something else that is wrong in my binary... I have to try again with less
>> changes and see if that works.
>> -Ville
>>
>> 2009/11/6 Christian <c.vossen@...>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
> .
>

The Checksum from 0000h to 5EFFh is
7EA4h

Stored at 5F00h-5F01h
7EA4



--- In BoschDME@yahoogroups.com, Ville Granfors <ville.granfors@...> wrote:
>
> Do you mean that if some value is upped some amount stuff bytes should be
> lowered same amount?
> Maby that is the reason why there is some FF turned to 00 in those binaries
> that I'm comparing.
> These files are now in files section. Binaries others, opel_motronic_543.zip
> This file contains original and  modified binary.
> From these files I can calculate checksum with hex workshop for area 2000 to
> 5f00 and it matches for value in 5f01, but if I make changes to binary and
> calculate new checksum for same area, check engine ligth is illuminated.
> Thats why I was thinking that there is another checksum, but maby there is
> something else that is wrong in my binary... I have to try again with less
> changes and see if that works.
> -Ville
>
> 2009/11/6 Christian <c.vossen@...>

You can use some stuff bytes to correct the checksum. This always works for me.

Regards,

Chris

--- In BoschDME@yahoogroups.com, Alexis Pavlov <alexis.pavlov@...> wrote:
>
> Hi,
> Send me your bin, I'll try to find where the checksum is calculated and
> you could switch it off.
> Alexis
>
> Ville Granfors wrote:
> >
> >
> > Can some one help me out with Opel motronic ML4.1 checksum?
> > I have been trying to change ignition tables for my ecu to suite better
> > for added turbo charger.
> > I have one "tuned" chip for NA engine for this same box an have been
> > comparing this and stock bin. By this compare I did found out that there
> > is attleast one checksum in  location 5f01. This I think is calculated
> > from 2000 to 5f00. At least I did get right answer for both bins by
> > using hex workshop application to calculate 8 bit checksum for that
> > area. But if I modify ignition tables and calculate new checksum check
> > engine light is illuminated. If I start car first with original bin and
> > after that load modified bin to eprom emulator check engine light is not
> > illuminated. From this I think that my problem is checksum related.
> > Does anyone in here have any ideas if there is more checksums or if I'm
> > calculating it from wrong place, or if my calculation is wrong?
> > WinOLS can calculate checksum for these bins, but I don't have that
> > program... And I think that it don't show what region it is using to
> > calculate checksum.
> >
> >
> >
>