TijnCU
Hero Member
Karma: +60/-4
 Offline
Posts: 690
flying brick
|
 |
« on: October 11, 2016, 09:49:34 AM »
|
|
|
I split this thread from my own project thread to have it in the right sub forum. It might be usefull to others! For some time I have been wanting to use kfzw1 for running more advanced timing maps. I drive on LPG, and map switching ignition is a perfect solution to gain effeciency. Since I use an AEB engine as base, I dont have VVT but the KFZW1 map is there nonetheless. Currently I run a wideband A4 ecu and customized narrowband harness. I came up with the idea of hacking the timing routine by replacing fnwue with a new variable that I can control. I will use the rear o2, variable ushk. For my application, just switching between 1 and 2 is enough but I thought this application of the function could be interesting for somebody that wants to do a flexfuel sensor and run E85 while making use of the Bosch designed interpolation between kfzw1 and 2 while fnwue is <1. Both fnwue and ushk are 8bit so controlling the factor with ushk would be as accurate as it is with cam switching. I'm really stoked about this idea, but maybe it will not work without other modifications to the code. I logged fnwue on my car, and with the engine running it is 0. So to fully understand what I need to do, lets take another look at the code that I have split into 3 sections seg010:EE22 sub_9EE22: ;ROUTINE FOR ABSOLUTE KFZW2 INPUT
seg010:EE22 mov [-r0], r9
seg010:EE24 mov [-r0], r7
seg010:EE26 mov [-r0], r6
seg010:EE28 sub r0, #2
seg010:EE2A extp #0E1h, #1 ; 'ß'
seg010:EE2E movb rl4, fnwue ;move fnwue to rl4 //replace with ushk to manipulate
seg010:EE32 cmpb rl4, #0FFh ;compare byte #0FFh to rl4 //0FFh is the maximum value of a byte.
seg010:EE36 jmpr cc_NZ, loc_9EE58 ;if the result is Not Zero, jump to next part of the routine. if the result is Zero, then
seg010:EE38 mov r12, #kfzw2 ;move contents of kfzw2 to r12
seg010:EE3C mov r13, #33A6h
seg010:EE40 mov r14, word_380C80
seg010:EE44 mov r15, word_380C92
seg010:EE48 calls 0, sub_78B8
seg010:EE4C movb rl7, rl4
seg010:EE4E movb zwnws, rl4
seg010:EE52 movb rl6, #0
seg010:EE54 jmpa cc_UC, loc_9EEE6 ;bypass kfzw1 routine
seg010:EE58 ; --------------------------------------------------------------------------- So, what I can conclude from this code is that fnwue=0 is passed in the ecu as a value of FF. I think that because if the difference between 0FFh and the value stored in fnwue has to be zero to actually run from the kfzw2 values. So, I need to find out what exact value I am giving to the ecu when I short the lambda2 input. Next part of the code: seg010:EE58
seg010:EE58 loc_9EE58: ;ROUTINE FOR ABSOLUTE KFZW1 INPUT
seg010:EE58 extp #0E1h, #1 ; 'ß'
seg010:EE5C movb rl4, fnwue ;move byte fnwue to rl4 // change this for ushk as well
seg010:EE60 jmpr cc_NZ, loc_9EE80 ;jump to interpolation part of routine if the conditionflag Not Zero is set
seg010:EE62 mov r12, #kfzw1 ;move contents of kfzw1 to r12
seg010:EE66 mov r13, #33A6h
seg010:EE6A mov r14, word_380C80
seg010:EE6E mov r15, word_380C92
seg010:EE72 calls 0, sub_78B8
seg010:EE76 movb rl6, rl4
seg010:EE78 movb zwnws, rl4
seg010:EE7C movb rl7, #0
seg010:EE7E jmpr cc_UC, loc_9EEE6 ;bypass interpolation routine
seg010:EE80 ; --------------------------------------------------------------------------- Now, if I understand this part correctly it means that when the byte of fnwue is at a value of 0, the conditionflag 'Not Zero' will not be set, and the content of kfzw1 is loaded into the registry. If there is any other value than 0 in fnwue, the routine jumps to the final section of code: seg010:EE80
seg010:EE80 loc_9EE80: ;ROUTINE FOR INTERPOLATION KFZW2+KFZW1
seg010:EE80 mov r12, #kfzw2
seg010:EE84 mov r13, #33A6h
seg010:EE88 mov r14, word_380C80
seg010:EE8C mov r15, word_380C92
seg010:EE90 calls 0, sub_78B8
seg010:EE94 extp #0E1h, #1 ; 'ß'
seg010:EE98 movbz r5, fnwue
seg010:EE9C mul r4, r5
seg010:EE9E mov r4, word_FE0E
seg010:EEA2 mov [r0], r4
seg010:EEA4 movb rl7, [r0+1]
seg010:EEA8 mov r12, #kfzw1
seg010:EEAC mov r13, #33A6h
seg010:EEB0 mov r14, word_380C80
seg010:EEB4 mov r15, word_380C92
seg010:EEB8 calls 0, sub_78B8
seg010:EEBC extp #0E1h, #1 ; 'ß'
seg010:EEC0 movbz r5, fnwue
seg010:EEC4 mov r2, #100h
seg010:EEC8 sub r2, r5
seg010:EECA mul r4, r2
seg010:EECC mov r4, word_FE0E
seg010:EED0 mov [r0], r4
seg010:EED2 movb rl6, [r0+1]
seg010:EED6 movb rl4, rl6
seg010:EED8 addb rl4, rl7
seg010:EEDA jmpr cc_NV, loc_9EEE2
seg010:EEDC movb rl4, #7Fh ; ''
seg010:EEE0 addcb rl4, #0 This is the part where from my understanding the interpolation and multiplication is done from the factor in fnwue. To hack the code and force kfzw1 I think I have 2 options: Find out what values my ushk gives when open and when shorted, if the shorted ushk gives a byte of 0 or 255 it follows the code and runs from either kfzw1 or kfzw2. The catch is that ushk must not give any other value than 255 or 0 or else it will go into interpolation mode. If the open or shorted ushk does not give 0, maybe I just make it jump to loc_9EE62 so it completes this part of the routine anyway. It will then run from kfzw1 and skip the interpolation part. The only problem in this situation is that I still need the 255 value or I will disable kfzw2. Lets find out!  Any comments or tips are welcome, I really suck at asm. I logged the variable ushk without any conversion, and it gives a value of 125 when its open and 38 when it is shorted to the output pin. I assume that these are the actual byte values. So either I need to change the ushk conversion, or just compare to 07Dh in code section #1 and change the jump in section #2. I´ll try to compile something and test it tonight  |
|
|
|
« Last Edit: October 12, 2016, 12:54:13 AM by TijnCU »
|
Logged
|
|
|
|
|
nubcake
|
|
« Reply #1 on: October 11, 2016, 10:40:54 AM »
|
|
|
What you're trying to achieve is pretty easy.
The "third" section is there to "blend" two maps together when the cams are in the process of switching. And two first ones are to save CPU time and avoid extra math when cams are in extreme positions.
There are multiple ways to approach this. I'd probably use one of the "filtering" functions and have smooth transition between maps, but that's fairly complicated for someone not familiar with asm.
If you just want "binary" action - just replace the "movb rl4, fnwue" with "movb rl4, ushk" and alter the comparison/jump conditions. Should be rather easy.
EDIT: check C166 instruction set manual for condition codes.
|
|
|
|
« Last Edit: October 11, 2016, 10:42:54 AM by nubcake »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #2 on: October 11, 2016, 10:46:16 AM »
|
|
|
yes, I did this "binary" coding with a little help of the C166ism and flashed it to my spare ecu. I just need to test if it works when the engine is running because on the bench I cannot see any difference if I short the rear o2 in/out. I put NOP instead of the #2 jump condition at EE60. This hacking is a good beginner solution because I can make use of the existing code. It gives me a better understanding how to do this kind of stuff  |
|
|
|
« Last Edit: October 11, 2016, 11:02:03 AM by TijnCU »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #3 on: October 11, 2016, 11:46:13 AM »
|
|
|
This hacking is a good beginner solution because I can make use of the existing code. It gives me a better understanding how to do this kind of stuff I really like this approach. Learn from something simple, so you can try more complicated things once you've figured the simple thing out. |
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #4 on: October 12, 2016, 05:03:05 AM »
|
|
|
I have made slight modifications to the code to ensure proper switching (changed the condition at adress EE58 to cc_ULE #070h, since the input reads either around 125 or 38 decimal). The thing that bothers me, is that ushk is now also used as a factor and it doesnt give out the right values. I think I localized the part where ushk gets its value, but I have not succeeded in changing the values so that it will give both 00 and FF. Here is a small part of the DHLSHK routine: *** I'm an idiot! sorry. Just after posting I thought, hey, I have a ram logger.... edited code below DHLSHK:
seg006:0572
seg006:0572 loc_50572: ; CODE XREF: DHLSHK+1AAj
seg006:0572 ; DHLSHK+1AEj
seg006:0572 mov r4, word_381B1A
seg006:0576 cmp r4, #1B4h ;change to cmp r4, #032h (built in margin for possible fluctuations of the variable, its not super stable)
seg006:057A jmpr cc_ULE, loc_50582 ;this condition is met when pin68 is open, so ushk will be set with 0 in the next part
seg006:057C movb ushk, ONES
seg006:0580 jmpr cc_UC, loc_505A6
seg006:0582 ; ---------------------------------------------------------------------------
seg006:0582
seg006:0582 loc_50582: ; CODE XREF: DHLSHK+1BAj
seg006:0582 mov r4, word_381B1A
seg006:0586 cmp r4, #0A4h
seg006:058A jmpr cc_NC, loc_50592 ; change to nop, ushk will be set to 0
seg006:058C movb ushk, ZEROS
seg006:0590 jmpr cc_UC, loc_505A6
seg006:0592 ; ---------------------------------------------------------------------------
seg006:0592
seg006:0592 loc_50592: ; this part of the code will now always be skipped
seg006:0592 mov r4, word_381B1A
seg006:0596 mov r5, r4
seg006:0598 shl r5, #4
seg006:059A sub r5, r4
seg006:059C sub r5, #99Ch
seg006:05A0 shr r5, #4
seg006:05A2 movb ushk, rl5
seg006:05A6
I think that word_381B1A is the actual voltage input or output on the c166. #1B4h translates into 436 decimal and that is exactly the reading that I get when I measure the output pin 69 on the ecu (436mV). Coincidence? After this, ushk receives either zero's or ones, which I understand to be the actual lambda monitoring (high or low). If the first 2 conditions are not met, it ends up in the last part where all sorts of magic happens with shifting bytes and stuff . I have verified that this currently gives the final output of ushk, because when I swapped the last with I got a value of 255 from logging ushk. The switching code is still untested, if my wife gets home before dark I'll wire the test ecu in. Logging word_381B1A gives a raw value of 42 when pin68 open, and 205 when shorted to 69. So I'll test if I can do something with these values in the jumping conditions... - added above. Still does not give out the desired/expected values on ushk. I'll try this: mov ushk, #0FFh
and
mov ushk, #000h |
|
|
|
« Last Edit: October 12, 2016, 07:01:30 AM by TijnCU »
|
Logged
|
|
|
|
|
vwaudiguy
|
|
« Reply #5 on: October 12, 2016, 08:54:25 AM »
|
|
|
if my wife gets home before dark I'll wire the test ecu in.
Sorry, but I thought this was funny. Also, flashlight? Also, great job! |
|
|
|
|
Logged
|
"If you have a chinese turbo, that you are worried is going to blow up when you floor it, then LOL."
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #6 on: October 12, 2016, 09:17:11 AM »
|
|
|
Haha well obviously I'm not allowed to go out tuning after sundown anymore.. I once loaded an untested flash in the car and let the wife test drive it to work the next morning at 06.15. After she woke the whole neighbourhood with a backfiring engine she made me swap the ecu on the street in my underwear  Flashlight is a good idea though  ok back on topic ECU harness wiring is done and I worked on the code a bit more. This is the asm code that I came up with to replace the function (and hex code behind it) seg006:0572 mov r4, word_381B1A F2 F4 1A 9B
seg006:0576 cmp r4, #032h 46 F4 32 00
seg006:057A jmpr cc_ULE, loc_50586 FD 05
seg006:057C mov b rl5, #0FFh E7 FA FF 00
seg006:0580 movb ushk, rl5 F7 FA 73 89
seg006:0584 jpmr cc_UC, loc_505A6 0D 0A
; ---------------------------------------------------------------------------
seg006:0586 movb rl5, #000h E7 FA 00 00
seg006:058A movb ushk, rl5 F7 FA 73 89
seg006:058E jmpr cc_UC, loc 505A6 0D 0D
; --------------------------------------------
seg006:05A6 I hope I did the counting correctly for the relative jumps, I looked how it was arranged in the code and try use the same approach. Its as clean as I think I can make it with my skills. ** aaaaaand I bricked it Back to the drawing board. I messed up with my cool ASCII code, I accidentally put it on line 058A  woops. Also the relative jumps where a bit off.. Honestly I dont fully understand how the relative jumps are calculated in this processor, it seemed to me in the original code 2 bytes were equal to 1 jump (03 skips 6 bytes eg. FF FF FF AA AA AA). Could be messing up if this is wrong... see attached image #2 for final code |
|
|
|
« Last Edit: October 12, 2016, 01:52:21 PM by TijnCU »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #7 on: October 12, 2016, 02:23:35 PM »
|
|
|
I have succesfully hacked ushk! It worked after I flashed the corrections in the code I made in the previous post, but now the variable ushk only gave 255 (meaning the second part of the code gets skipped). The problem was that word_381B1A is 16bit. I logged it with the adjusted *ecu file and it gave 298 as the open value and 205 when I shorted the pins. So after I corrected the jump condition from #032h to #0FFh, it works! Logger result screenshot attached The beauty of this detour is now that I could repair the fnwue routine to its original except 4 bytes (fnwue=ushk). Ecu still runs after 5 key cycles, do I need to worry about later unexpected checksum errors or is this coding all outside of checksum areas? I exported the final map with winols so checksums should be good... |
|
|
|
« Last Edit: October 12, 2016, 02:53:23 PM by TijnCU »
|
Logged
|
|
|
|
|
nubcake
|
|
« Reply #8 on: October 12, 2016, 04:12:04 PM »
|
|
|
2 bytes were equal to 1 jump (03 skips 6 bytes eg. FF FF FF AA AA AA). This. The problem was that word_381B1A is 16bit That's why it's a word, not a byte. Ecu still runs after 5 key cycles, do I need to worry about later unexpected checksum errors or is this coding all outside of checksum areas? I exported the final map with winols so checksums should be good... I always double-check with me7check. Takes 5 seconds anyways. EDIT:Also, as a word of advice: avoid patching the "input" to existing vars like that. You could miss a write reference or two - and your code (relying on them being in specific condition) might go haywire on you at random moment of time. Besides, there could be numerous other functions that interact with said var - and they will also go nuts if they see something unexpected. I'd say you should rather patch ZWGRU like you planned initially, it's a much "cleaner" approach - you patch only what you plan to use. Change the "fnwue" reference and a couple of compare/jump conditions - it's even easier than messing with the ushk. |
|
|
|
« Last Edit: October 12, 2016, 04:23:59 PM by nubcake »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #9 on: October 13, 2016, 12:37:27 AM »
|
|
|
Haha, duhhh. I actually knew the difference between words and bytes but in the focus on the code I totally forgot to apply anything I had learned. Total beginner I appreciate your feedback on my approach! Sometimes when I get caught up in my work I cant really think of alternatives. I understand that it is more work to check all references to ushk than only hacking the ZWGRU routine. My idea was (and maybe this was a false assumption) that I dont use the rear o2 anyway (its coded out) and I need no further functionality from it. I will reassess my ushk hack and doublecheck all xrefs. I do recall a topic about logging wideband on the rear o2 input that set off all kind of fuel trims in ME7.1 so your warning might directly apply on my case. If I find any xref to ushk that leads to another function I'll redo the work. I suspect that word_381B1A1 is used for functionality beyond ushk (word_381B1A1 is the input to ushk and is not altered), but its good to check again. Even the shorting of the pins could lead to errors in other functions since that does affect the output of word_381B1A1. It was more my fear about what would happen with my input in rl4 in the ZWGRU part, since beyond the switching that # remains in the register. That was why I would rather alter the function I (thought I) didnt use and put a logic value in the function that I do use. Maybe this is completely paranoia though Thanks again for your feedback |
|
|
|
« Last Edit: October 13, 2016, 03:32:53 AM by TijnCU »
|
Logged
|
|
|
|
|
nubcake
|
|
« Reply #10 on: October 13, 2016, 02:36:40 AM »
|
|
|
It was more my fear about what would happen with my input in rl4 in the ZWGRU part, since beond the switching that # remains in the register. Check the code "downstream" of that write to confirm that it's not used. It usually is overwritten very soon with something else, but never hurts to confirm yourself. In that particular case you just need to mod the first comparison condition and "nop" out the second one to completely bypass the "map blending" part. |
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #11 on: October 13, 2016, 03:36:12 AM »
|
|
|
I just tested both versions (with ushk mod and with only the zwgru changes) but the car wont run properly on either of the flashes, no matter if the rear o2 pins are shorted or not. So there is probably something I missed. I'll dive back into the asm and find out what is going on  * Might be that the ecu still tries to interpolate with kfzw1 (that I set to 0 over the whole map to test) while I expected it to run off kfzw2 entirely. The variable zwgru was constantly at or around 0 in the logger. If I can get it to run good when I clone the kfzw maps, I maybe just need to disable the interpolation routine. complete original subroutine below seg010:EE22 ; =============== S U B R O U T I N E =======================================
seg010:EE22
seg010:EE22
seg010:EE22
seg010:EE22 sub_9EE22:
seg010:EE22 mov [-r0], r9
seg010:EE24 mov [-r0], r7
seg010:EE26 mov [-r0], r6
seg010:EE28 sub r0, #2
seg010:EE2A extp #0E1h, #1 ; 'ß'
seg010:EE2E movb rl4, fnwue
seg010:EE32 cmpb rl4, #0FFh
seg010:EE36 jmpr cc_NZ, loc_9EE58
seg010:EE38 mov r12, #kfzw2
seg010:EE3C mov r13, #33A6h
seg010:EE40 mov r14, word_380C80
seg010:EE44 mov r15, word_380C92
seg010:EE48 calls 0, sub_78B8
seg010:EE4C movb rl7, rl4
seg010:EE4E movb zwnws, rl4
seg010:EE52 movb rl6, #0
seg010:EE54 jmpa cc_UC, loc_9EEE6
seg010:EE58 ; ---------------------------------------------------------------------------
seg010:EE58
seg010:EE58 loc_9EE58: ; CODE XREF: sub_9EE22+14j
seg010:EE58 extp #0E1h, #1 ; 'ß'
seg010:EE5C movb rl4, fnwue
seg010:EE60 jmpr cc_NZ, loc_9EE80
seg010:EE62 mov r12, #kfzw1
seg010:EE66 mov r13, #33A6h
seg010:EE6A mov r14, word_380C80
seg010:EE6E mov r15, word_380C92
seg010:EE72 calls 0, sub_78B8
seg010:EE76 movb rl6, rl4
seg010:EE78 movb zwnws, rl4
seg010:EE7C movb rl7, #0
seg010:EE7E jmpr cc_UC, loc_9EEE6
seg010:EE80 ; ---------------------------------------------------------------------------
seg010:EE80
seg010:EE80 loc_9EE80: ; CODE XREF: sub_9EE22+3Ej
seg010:EE80 mov r12, #kfzw2
seg010:EE84 mov r13, #33A6h
seg010:EE88 mov r14, word_380C80
seg010:EE8C mov r15, word_380C92
seg010:EE90 calls 0, sub_78B8
seg010:EE94 extp #0E1h, #1 ; 'ß'
seg010:EE98 movbz r5, fnwue
seg010:EE9C mul r4, r5
seg010:EE9E mov r4, word_FE0E
seg010:EEA2 mov [r0], r4
seg010:EEA4 movb rl7, [r0+1]
seg010:EEA8 mov r12, #kfzw1
seg010:EEAC mov r13, #33A6h
seg010:EEB0 mov r14, word_380C80
seg010:EEB4 mov r15, word_380C92
seg010:EEB8 calls 0, sub_78B8
seg010:EEBC extp #0E1h, #1 ; 'ß'
seg010:EEC0 movbz r5, fnwue
seg010:EEC4 mov r2, #100h
seg010:EEC8 sub r2, r5
seg010:EECA mul r4, r2
seg010:EECC mov r4, word_FE0E
seg010:EED0 mov [r0], r4
seg010:EED2 movb rl6, [r0+1]
seg010:EED6 movb rl4, rl6
seg010:EED8 addb rl4, rl7
seg010:EEDA jmpr cc_NV, loc_9EEE2
seg010:EEDC movb rl4, #7Fh ; ''
seg010:EEE0 addcb rl4, #0
seg010:EEE2
seg010:EEE2 loc_9EEE2: ; CODE XREF: sub_9EE22+B8j
seg010:EEE2 movb zwnws, rl4
seg010:EEE6
seg010:EEE6 loc_9EEE6: ; CODE XREF: sub_9EE22+32j
seg010:EEE6 ; sub_9EE22+5Cj
seg010:EEE6 movbs r9, rl6
seg010:EEE8 movbs r4, rl7
seg010:EEEA add r9, r4
seg010:EEEC movbs r4, byte_380AED
seg010:EEF0 add r9, r4
seg010:EEF2 movbs r4, byte_380AEE
seg010:EEF6 add r9, r4
seg010:EEF8 movbs r4, byte_380B8A
seg010:EEFC add r9, r4
seg010:EEFE cmp r9, #7Fh ; ''
seg010:EF02 jmpr cc_SLT, loc_9EF0E
seg010:EF04 movb rl4, #7Fh ; ''
seg010:EF08 movb zwgru, rl4
seg010:EF0C jmpr cc_UC, loc_9EF24
seg010:EF0E ; ---------------------------------------------------------------------------
seg010:EF0E
seg010:EF0E loc_9EF0E: ; CODE XREF: sub_9EE22+E0j
seg010:EF0E cmp r9, #0FF80h
seg010:EF12 jmpr cc_SGE, loc_9EF1E
seg010:EF14 movb rl4, #80h ; 'Ç'
seg010:EF18 movb zwgru, rl4
seg010:EF1C jmpr cc_UC, loc_9EF24
seg010:EF1E ; ---------------------------------------------------------------------------
seg010:EF1E
seg010:EF1E loc_9EF1E: ; CODE XREF: sub_9EE22+F0j
seg010:EF1E mov r4, r9
seg010:EF20 movb zwgru, rl4
seg010:EF24
seg010:EF24 loc_9EF24: ; CODE XREF: sub_9EE22+EAj
seg010:EF24 ; sub_9EE22+FAj
seg010:EF24 add r0, #2
seg010:EF26 mov r6, [r0+]
seg010:EF28 mov r7, [r0+]
seg010:EF2A mov r9, [r0+]
seg010:EF2C rets
seg010:EF2C ; End of function sub_9EE22 |
|
|
|
« Last Edit: October 13, 2016, 07:39:25 AM by TijnCU »
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #12 on: October 18, 2016, 03:57:44 AM »
|
|
|
I've let this rest for a couple of days, but yesterday I wanted to get the function to work. I started from scratch, and I took nubcake's advice at heart so the function now only uses unmodified existing variables. fnwue is not being used in the equation in the first 2 map selection sections and r(l)4 gets overwritten with the contents of kfzw in the subroutine that gets called. The big issue is that I cannot get the function to switch  I can hardcode kfzw1 or 2, and to verify I have nop'd the interpolation part of the routine as well but I have not yet succeeded in making the first jump dynamic based on my input. word_381B1A1 represents ~012A (298) when untriggered and ~00CD (205) when triggered I'm currently re-reading all of the flags that can be set in different situations to find out what I need to do to keep it compact and functional. I have tried various cmp and cmpb variations from both word_381B1A1 or ushk (8bit) but it looks like it never makes the jump unless I make the jump unconditional. I cant get my head wrapped around why it will not become dynamic. sigh... this easy map switching is still damn hard for a beginner in asm  To me it seems that mov r3, word_381b1a
cmp r3, #0FFh
will set the V(underflow) flag when word_381b1a<FF, right? I cant do any Z flags because the variable is not completely stable. |
|
|
|
« Last Edit: October 18, 2016, 05:28:53 AM by TijnCU »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #13 on: October 18, 2016, 05:50:08 AM »
|
|
|
Much easier - substitute R12 write before map lookup with a call to this (obviously edit the variable addresses):
;Constants
failsafe_status EQU 0x0F26 + 0x8000 ;B1S2 ADC
voltage_threshold EQU 0x200 ; 2.5 volts
;0x811F71
kfzw_norm_start_addr EQU #0x1EB1
;0x8171E6
kfzw_meth_start_addr EQU #0x71E6
switch_kfzw proc far
MOV R12, failsafe_status
CMP R12, #voltage_threshold
JMPR cc_c, not_ok2
MOV R12, #kfzw_meth_start_addr
RETS
not_ok2:
MOV R12, #kfzw_norm_start_addr
RETS
switch_kfzw endp
|
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #14 on: October 18, 2016, 06:11:07 AM »
|
|
|
Thanks for your contribution prj, I see this is clearly the best approach to switch both kfzw maps for substitutes when you have the variable cam in place. I thought I found a shortcut (and in theory it should work ) to do without a call to a new subroutine when you have a fixed cam, but I'll do this when the last attempt fails too. Its still nice that I have messed with the code because I learned new stuff Btw, do you use the o2 signal in/out of the ecu or the heater pins? I found that the ecu reboots when I put another voltage on the o2 input... |
|
|
|
« Last Edit: October 18, 2016, 07:28:40 AM by TijnCU »
|
Logged
|
|
|
|
|
