ME7.9.10 - Understanding the torque model

Pages: 1 ... 11 12 [13] 14 15 ... 26

« previous next »

Author

Topic: ME7.9.10 - Understanding the torque model (Read 200122 times)

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #180 on: April 19, 2018, 10:24:55 AM »

I got a private message asking about some boot mode details for this ECU, thought I'd share the answer here so that everybody can benefit. The ECU pins and the boot mode connection is as on the picture from FGTechnology. But, it is not necessary to solder, without professional equipment you can make a contraption like mine from a female header part. The needle you stick into a pin hole that is nearby on the board where the right resistor is soldered, just trace the connection (you can even do it on the picture when you magnify). Then hold the rest of the contraption against the pads and voila. For the ECU pin connections (the picture is crappy) - the 12V is the 3rd from the left, the K-line is 4th. (I actually got this wrong on my first connection attempt :/).


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #181 on: April 29, 2018, 02:18:52 PM »

I sort of failed with one thing, for a couple of weeks I have been testing different CD(X) and CLA(X) configurations to code out the post cat lambda. Just coding out is no problem - I can disconnect the sensor and won't get trouble / DTCs keeping the pre-cat lambda working and correcting. One curiosity in this was that off-ing CD(X) generally disables the corresponding DTC, but not for HSHE, here setting CD to 0 does not kill the DTC, the error class has to be set to 0 too.

But I was attempting to code it out such that the readiness is not disturbed, that is, it comes back eventually after DTC reset. The readiness on this ECU is only reported through the OBD-II request 0101, and out of sensitive things it is only cat efficiency, lambda heater(s), and lambda sensor(s). The cat readiness comes back practically immediately (one key-on cycle IIRC), the lambda heater readiness comes back after a couple of drives. The lambda sensor itself readiness I could not make to come back (it takes a while even on a healthy / stock setup, so I took my time and proper drives when testing too). Looking at the code, all three are treated the same (a specific configuration of DTC status for each component is checked), but the lambda sensor status just won't clear out. How and when the involved DTCs are manipulated is a bit difficult to see through in the code (and hence my inability to solve this puzzle for now).

Understand me well - forcefully making the readiness to come back is not a problem, several different code hacks are possible to make it work, including secret interactions with car equipment or custom CAN messages to make it clear out, not talking about hard-coding in fixed readiness flags. But I was looking for a clean calibration data only way, and I cannot find it for the core sensor readiness, though it does work for cat and the heater readiness. A bit stumped here to be honest, probably missing something obvious, hence this rambling Wink


	Logged

nubcake

Sr. Member

Karma: +53/-4
Offline

Offline

Posts: 400

	Re: ME7.9.10 - Understanding the torque model « Reply #182 on: April 29, 2018, 04:15:44 PM »

I don't have any experience with this particular ECU, so whatever I write below might be irrelevant for it.
For the heater there can also be a CWPSHSHE.
For readiness - CWKONLS present here at all?


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #183 on: April 30, 2018, 12:21:20 AM »

Quote from: nubcake on April 29, 2018, 04:15:44 PM

I don't have any experience with this particular ECU, so whatever I write below might be irrelevant for it.
For the heater there can also be a CWPSHSHE.
For readiness - CWKONLS present here at all?

CWPSHSHE is not mentioned anywhere in the reference definition, and also - heater is not a problem, readiness comes back.

CWKONLS - yes, it's there, have not played with it, will check it out, thanks! The stock value is 0x03.


	Logged

teobolo

Full Member

Karma: +24/-6
Offline

Offline

Posts: 112

	Re: ME7.9.10 - Understanding the torque model « Reply #184 on: April 30, 2018, 05:19:39 AM »

Quote from: woj on April 30, 2018, 12:21:20 AM

according to the wiki and hoping is tha same for me7.9.10 you must set 0x03 to 0x01 ( CWKONLS (0x181BB) - Vehicles with 4 installed sensors - change from 51 (0x33/00110011b) to 17 (0x11/00010001b)[55] Vehicles with 2 installed sensors (default value 3), set to 1 )


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #185 on: April 30, 2018, 05:35:21 AM »

Precisely, bit 0 (0x01) is the pre-cat sensor, bit 1 (0x02) is the post-cat sensor, running the car with 0x01 to test right now. One thing I know already is that this still does not kill DTC P0141 for HSHE, this still needs the error class set to 0 apart from the diagnosis code word.


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #186 on: April 30, 2018, 12:20:50 PM »

OK, this was eating me enough to look deeper into the code and log some RAM cells. After this I know almost for certain that it is because of LASH - CDLASH makes the code totally skip the call to set_DTC for this, which leaves all DTC flags at zero, while they need to be at "I checked and found nothing wrong state", that is, bit#0 has to be 0, but bit#1 needs to be 1. For the other lambda related things killing diagnosis causes the code to register DTC as checked and correct. The only thing that is now not obvious is to how to make it so for LASH too. But I am closer. (Probably CDLASH back to on, but DTC class to zero).


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #187 on: May 01, 2018, 06:27:20 AM »

OK, I am clearly on to something. This thing I said that off-ed CDLASH is skipping DTC registration altogether is clearly a bug, because in another bin (Abarth) this is done properly and exactly as I would like it to be - CDLASH off -> register clean DTC status. In my case registration is not done.

Sadly, the code is not fixable without "stepping out of its boundaries", brrr...


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #188 on: May 03, 2018, 12:52:30 AM »

Sorted!

Below my changes to code out the second lambda such that the readiness comes back after DTC reset. The actual code fix for CDLASH I will describe later (it turned out it is doable in-situ), not all of the bins will need it. Setting CLAHSHE to 00 is necessary (other non zero class might work too, but 03 does not), despite killing diagnosis with CDHSHE P0141 (O2 sensor heater (post-cat)) comes up almost immediately and is resistant to DTC resets. I have not yet figured out exactly why it is so, but I know two things: the DTC is registered once per key-on / DTC reset, and the factory DTC class for this (03) might have something to do with it. Further, not modifying CWKONLS might work, but since each test takes a proper 15 minute drive, I can't be bothered to test more configurations. And clearing the LSH bit in CWKONLS is not unreasonable to do anyhow. Also, the LASH related things might be solvable by proper CD/CLA configuration and no code patch, but see the previous point.

As far as readiness is concerned this config has only one visible difference from the healthy factory setup - the catalyst readiness clears immediately, while normally it takes some driving. The O2 sensor and heater both exhibit the same behaviour, heater comes back after "some" engine starts, the sensor after proper drive(s). Of course, the fact that the OBD readings for the second lambda voltage are dead gives away that something has been manipulated, nevertheless this is as far as one can get to faking it without very serious code hacks.

If not for this factory code glitch, this would have been sorted out practically on the first attempt, took me over two weeks of tests... :/


« Last Edit: May 03, 2018, 12:54:52 AM by woj »	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #189 on: May 03, 2018, 11:57:47 AM »

So, below the factory entry to the LASH diagnosis procedure. xram2_byte_0F030E.6 checked at 045696 is a RAM copy of the CDLASH flag. When not set it jumps almost to the exit of the procedure, no set_DTC is ever called. The jump has to be redirected to a place where a clean DTC is registered (here 0466B2), but it is not as simple as just changing the jump address. The DTC setting code needs to have the current DTC status word (xram_word_F35FE) at [r0], which is not yet there when the jump call at 04569A is made. Lucikly, the code at 0456B4..0456BA is a NOP and this 8 byte space can be utilised to fix this.

Code:

sub_04567C:
        flash_04567C:[88,90]            mov     [-r0], r9
        flash_04567E:[88,80]            mov     [-r0], r8
        flash_045680:[88,70]            mov     [-r0], r7
        flash_045682:[88,60]            mov     [-r0], r6
        flash_045684:[28,02]            sub     r0, #2
        flash_045686:[4A,2F,FC,9F]      bmov    r12.15, iram_word_FD5E.9
        flash_04568A:[D7,40,2C,00]      extp    #0x2C, #1
        flash_04568E:[F3,FC,80,03]      movb    rl6, data_byte_0B0380
        flash_045692:[F3,F2,0E,83]      movb    rl1, xram2_byte_0F030E
        flash_045696:[8A,F1,02,60]      jb      r1.6, loc_04569E
loc_04569A:
        flash_04569A:[EA,00,40,67]      jmpa    cc_UC, loc_046740
loc_04569E:
        flash_04569E:[F3,F4,41,84]      movb    rl2, xram2_byte_0F0441
        flash_0456A2:[8A,F2,02,70]      jb      r2.7, loc_0456AA
loc_0456A6:
        flash_0456A6:[6F,88]            bset    PSW.USR0
        flash_0456A8:[0D,01]            jmpr    cc_UC, loc_0456AC
loc_0456AA:
        flash_0456AA:[6E,88]            bclr    PSW.USR0
loc_0456AC:
        flash_0456AC:[3A,88,F8,6C]      bmovn   r8.12, PSW.USR0
        flash_0456B0:[84,00,FE,B5]      mov     [r0], xram2_word_0F35FE
        flash_0456B4:[F2,F9,1C,FF]      mov     r9, ZEROS
        flash_0456B8:[48,90]            cmp     r9, #0
        flash_0456BA:[3D,02]            jmpr    [cc_NZ,cc_NE], loc_0456C0
loc_0456BC:
        flash_0456BC:[9A,F6,09,20]      jnb     r6.2, loc_0456D2
loc_0456C0:
        [...]
loc_046740:
        flash_046740:[F3,FC,3F,84]      movb    rl6, xram2_byte_0F043F
        flash_046744:[9A,F6,05,00]      jnb     r6.0, loc_046752
loc_046748:
        flash_046748:[E7,FE,10,00]      movb    rl7, #0x10
        flash_04674C:[75,FE,3F,84]      orb     xram2_byte_0F043F, rl7
        flash_046750:[0D,04]            jmpr    cc_UC, loc_04675A
loc_046752:
        flash_046752:[E7,FC,EF,00]      movb    rl6, #0xEF
        flash_046756:[65,FC,3F,84]      andb    xram2_byte_0F043F, rl6
loc_04675A:
        flash_04675A:[08,02]            add     r0, #2
        flash_04675C:[98,60]            mov     r6, [r0+]
        flash_04675E:[98,70]            mov     r7, [r0+]
        flash_046760:[98,80]            mov     r8, [r0+]
        flash_046762:[98,90]            mov     r9, [r0+]
        flash_046764:[DB,00]            rets

The fixed version is (with 2 bytes to spare):

Code:

sub_04567C:
        flash_04567C:[88,90]            mov     [-r0], r9
        flash_04567E:[88,80]            mov     [-r0], r8
        flash_045680:[88,70]            mov     [-r0], r7
        flash_045682:[88,60]            mov     [-r0], r6
        flash_045684:[28,02]            sub     r0, #2
        flash_045686:[4A,2F,FC,9F]      bmov    r12.15, iram_word_FD5E.9
        flash_04568A:[D7,40,2C,00]      extp    #0x2C, #1
        flash_04568E:[F3,FC,80,03]      movb    rl6, data_byte_0B0380
        flash_045692:[F3,F2,0E,83]      movb    rl1, xram2_byte_0F030E
        flash_045696:[8A,F1,02,60]      jb      r1.6, loc_04569E
loc_04569A:
        flash_04569A:[0D,0A]            jmpr    cc_UC, loc_0456B0
        flash_04569C:[CC,00]            db      0xCC, 0x00
loc_04569E:
        flash_04569E:[F3,F4,41,84]      movb    rl2, xram2_byte_0F0441
        flash_0456A2:[8A,F2,02,70]      jb      r2.7, loc_0456AA
loc_0456A6:
        flash_0456A6:[6F,88]            bset    PSW.USR0
        flash_0456A8:[0D,01]            jmpr    cc_UC, loc_0456AC
loc_0456AA:
        flash_0456AA:[6E,88]            bclr    PSW.USR0
loc_0456AC:
        flash_0456AC:[3A,88,F8,6C]      bmovn   r8.12, PSW.USR0
loc_0456B0:
        flash_0456B0:[84,00,FE,B5]      mov     [r0], xram2_word_0F35FE
        flash_0456B4:[8A,F1,02,60]      jb      r1.6, loc_0456BC
loc_0456B8:
        flash_0456B8:[EA,00,B2,66]      jmpa    cc_UC, loc_0466B2
loc_0456BC:
        flash_0456BC:[9A,F6,09,20]      jnb     r6.2, loc_0456D2
loc_0456C0:
        [...]
loc_0466B2:
        flash_0466B2:[A8,80]            mov     r8, [r0]
        flash_0466B4:[66,F8,FE,FF]      and     r8, #0b1111111111111110
        flash_0466B8:[B8,80]            mov     [r0], r8
        flash_0466BA:[A8,90]            mov     r9, [r0]
        flash_0466BC:[66,F9,FF,F0]      and     r9, #0b1111000011111111
        flash_0466C0:[B8,90]            mov     [r0], r9
        flash_0466C2:[0D,30]            jmpr    cc_UC, loc_046724
        [...]
loc_046724:
        flash_046724:[A8,80]            mov     r8, [r0]
        flash_046726:[78,82]            or      r8, #0b00000010
        flash_046728:[B8,80]            mov     [r0], r8
        flash_04672A:[A8,90]            mov     r9, [r0]
        flash_04672C:[76,F9,00,20]      or      r9, #0b0010000000000000
        flash_046730:[B8,90]            mov     [r0], r9

        flash_046732:[A8,80]            mov     r8, [r0]
        flash_046734:[88,80]            mov     [-r0], r8
        flash_046736:[E6,FC,33,00]      mov     r12, #0x0033
        flash_04673A:[DA,03,E8,20]      calls   set_DTC_0320E8
        flash_04673E:[08,02]            add     r0, #2
        [...]

The actual patch to do this is very short:

Code:

org     $4569A
        jmpr    cc_UC, $456B0
        nop
org     $456B4
        jb      r1.6, $456BC
        jmpa    cc_UC, $466B2

For completeness, this is the entry to this procedure in the Abarth bin:

Code:

sub_042CA8:
        flash_042CA8:[88,90]            mov     [-r0], r9
        flash_042CAA:[88,80]            mov     [-r0], r8
        flash_042CAC:[88,70]            mov     [-r0], r7
        flash_042CAE:[88,60]            mov     [-r0], r6
        flash_042CB0:[28,02]            sub     r0, #2
        flash_042CB2:[4A,30,FC,EF]      bmov    r12.15, iram_word_FD60.14
        flash_042CB6:[D7,40,2C,00]      extp    #0x2C, #1
        flash_042CBA:[F3,FC,8A,05]      movb    rl6, data_byte_0B058A
        flash_042CBE:[F3,F2,0E,83]      movb    rl1, xram2_byte_0F030E
        flash_042CC2:[8A,F1,04,60]      jb      r1.6, loc_042CCE
loc_042CC6:
        flash_042CC6:[84,00,44,BB]      mov     [r0], xram2_word_0F3B44
        flash_042CCA:[EA,00,E2,3C]      jmpa    cc_UC, loc_043CE2
loc_042CCE:

where 043CE2 is what 0466B2 is above in the other bin. And that is what I guess was intended from the start.

Onto the next thing, which I am not sure what it will be... Have to finally mount my AFR setup, which is the whole reason for this exercise.


« Last Edit: May 03, 2018, 11:59:26 AM by woj »	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #190 on: May 10, 2018, 12:44:22 PM »

Nothing really that noteworthy, not there yet, but I am slowly making moves to try my flex fuel setup Wink


	Logged

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #191 on: May 12, 2018, 12:27:20 PM »

My flex fuel setup and development is working Cheesy

. For now I disabled any corrections / blending (one flag will turn them on), I only measure what is in the regular fuel in the country, turns out 4.8% ethanol (what I have in the tank right now is around 70% 95 with 30% Shell V-power 98). Or, to be more precise, there is 95.2% gasoline in it, because this is what the sensor in fact measures. This I will use to calibrate the blendings more precisely before I pour in the real E85 (I also was stupid enough to fill up with gasoline just two days ago, no space in the tank, and my WBO still awaits installation).

The sensor is plugged in directly into the ECU, and I process the phase / frequency with a free interrupt (according to the t-jet docs, this was originally meant to be oil condition sensor). Hence I get both the E-content and fuel temperature. The contraption in the picture is a temporary setup to be easily removable if something goes wrong. If/when i decide to go with this long term I will clean up this mess.

There is one curiosity with all this, and it has to do with fluid mechanics more than with programming. The air reads as 100% gasoline, hence any air pockets in the fuel line skew the reading. And since this is a return line, that happens easily, especially with just the ignition on and no fuel pump running. I actually anticipated this and programmed a delay - when the fuel pump is off the last know good reading is used and before the new one is taken the fuel pump has to be on for at least a given amount of time. Experimenting with this is visible on the video, not perfect, but better than the first startup on the video. This is actually a bit complex, the amount of time the car was left standing also affects this. Probably the best solution is to mount a one way valve (I think I even have one somewhere) after the sensor to (a) provide some small resistance on the line (quicker fill), (b) prevent air backing in from the line. This is only important during startup, nevertheless, since E85 is known not to start well when cold one would like to get precise readings during the start up phase to get the corrections right.

The clip: https://youtu.be/N2w4-gKWHS4

To be continued...


	Logged

prj

Hero Member

Karma: +1072/-480
Offline

Offline

Posts: 6034

	Re: ME7.9.10 - Understanding the torque model « Reply #192 on: May 12, 2018, 12:34:55 PM »

The correct approach is to let the ECU run the fuel pump until the E85 sensor reading stays static.
Check valve is gonna do absolutely nothing on a return line, especially AFTER the sensor. Think a bit which way fuel flows.


	Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches

woj

Hero Member

Karma: +43/-3
Offline

Offline

Posts: 500

	Re: ME7.9.10 - Understanding the torque model « Reply #193 on: May 12, 2018, 12:58:05 PM »

Quote from: prj on May 12, 2018, 12:34:55 PM

The correct approach is to let the ECU run the fuel pump until the E85 sensor reading stays static.

So, scenario when you turn the key to ignition on and then start the engine immediately is out of picture, the pump will run constantly.

For the other one - you turn the ignition on, but no start - well, I did build the fuel up in the line by doing several key-ons and I had a stable static reading of 4.8% after this with ECU waiting for start up. Yet, the reading still drops momentarily (down to 1.x%) when I crank it. (It can be due to voltage drop, but I have no means of verifying this, I did google for battery voltage corrections for flex fuel sensors, no mentioning of this, so I assume that's not it).

So you are right I guess, but that applies only to the first reading with no engine start (which would remedy my 3.X% reading on the first part of the video, this was after I left the car for some time). But I really want to remedy the case above. I will have to test more, because I am now running regular fuel, I have no clue how this will behave with E85. Anyhow, testing phase, will sort it out with time.


	Logged

jcsbanks

Full Member

Karma: +19/-3
Offline

Offline

Posts: 146

	Re: ME7.9.10 - Understanding the torque model « Reply #194 on: May 12, 2018, 01:29:22 PM »

Well done for hacking the interrupt. I wanted to do that on MEVD17, but I could not find a spare suitable input that was available across all model variants (eg BMW M3/4 S55 uses the ethanol content input for the second MAF sensor) so I put it in through CAN.

What I do is store the ethanol content in EEPROM on ECU shutdown. This way there is a valid value at next start if a new one has not been received for some reason. I also do not send wildly fluctuating values on the CAN bus to the ECU, so there is a gradient filter and error check for no CAN frame received within the last 10 seconds throwing a check engine light. I could add more checks if needed, but with sensors used in the feed line on my target platforms I think I've done enough. One I considered was to average ethanol readings over an increasing period based on the time since engine start, or compare fuel level at restart compared with last shutdown to see if it is plausible that there is a new ethanol content, but it really doesn't seem necessary.


« Last Edit: May 12, 2018, 01:33:11 PM by jcsbanks »	Logged

Pages: 1 ... 11 12 [13] 14 15 ... 26

« previous next »

Jump to:

Navigation

Personal Tools

November 22, 2024, 06:37:52 AM

Welcome, Guest. Please login or register.
Did you miss your activation email?

Navigation

Personal Tools

Search