Pages: [1]
Author Topic: McMess syncronous crank read -> am i blind ?!!!  (Read 5986 times)
fluke9
Full Member
***

Karma: +26/-1
Offline Offline

Posts: 113


« on: October 16, 2019, 02:16:18 PM »

Got mcmess syncronous crankshaft reading running, but only once...
I switch to sync mode by 3d and begin to send my bytes in a the timeslots i want the results but it only returns the 6 bytes once,
then craps out.

What i can think of is that S0RBUF is filled with its own answers and it branches out the check in 0x82246E or is there a way either with S0CON or any other way that i does not see its own answers?
Does Bosch run mcmess with seperate rx/tx ?

As i want to patch it later on relocate ram to a bigger table i might patch that anyway but i am just wondering.

The function on the crank trigger looks like this:

Code:
 
822450 MCMessSyncroPush:                       ; CODE XREF: sub_821226+9C↑P
822450                 mov     [-r0], r9
822452                 mov     [-r0], r8
822454                 movb    rl4, asc0_ComMode ; 0x1? == McMess
822458                 cmpb    rl4, #15h
82245C                 jmpa    cc_NZ, _mcm_out
822460                 mov     r8, S0RBUF
822464                 movb    nosync_TimoutCounter, ZEROS
822468                 mov     r4, #100h
82246C                 and     r4, r8
82246E                 cmp     r4, #100h
822472                 jmpr    cc_NZ, _1AA_ENDCOMM
822474                 cmp     r8, #1AAh
822478                 jmpr    cc_Z, return_to_normal_mcmess
82247A                 mov     r4, #10h
82247E                 or      asc0_Bits, r4
822482                 bclr    S0TIR
822484                 mov     r9, #1
822486
822486 loc_822486:                             ; CODE XREF: MCMessSyncroPush+4E↓j
822486                 mov     r4, r9
822488                 shl     r4, #2
82248A                 mov     r10, [r4+mcMessSynchroTab]
82248E                 mov     r11, [r4+8E86h]
822492                 exts    r11, #1
822494                 movb    rl4, [r10]
822496                 movb    [r9+asc0_CommunicationBuf], rl4
82249A                 add     r9, #1
82249C                 cmp     r9, #6
82249E                 jmpr    cc_C, loc_822486
8224A0                 bset    S0TIE
8224A2                 mov     r4, #unk_E0A5
8224A6                 mov     SRCP6, r4
8224AA                 mov     PECC6, #505h
8224AE                 mov     r4, mcMessSynchroTab
8224B2                 mov     r5, word_380E86
8224B6                 exts    r5, #1
8224B8                 movb    rl3, [r4]
8224BA                 movbz   r2, rl3
8224BC                 mov     S0TBUF, r2
8224C0                 jmpr    cc_UC, _mcm_out
8224C2 ; ---------------------------------------------------------------------------
8224C2
8224C2 _1AA_ENDCOMM:                           ; CODE XREF: MCMessSyncroPush+22↑j
8224C2                 calls   82h, endMcMessAndShutdown_821AE6
8224C6                 jmpr    cc_UC, _mcm_out
8224C8 ; ---------------------------------------------------------------------------
8224C8
8224C8 return_to_normal_mcmess:                ; CODE XREF: MCMessSyncroPush+28↑j
8224C8                 mov     r4, #0FFFBh
8224CC                 and     asc0_Bits, r4
8224D0                 bclr    S0RIR
8224D2                 bclr    S0TIR
8224D4                 mov     r4, #155h
8224D8                 mov     asc0_CommunicationBuf, r4
8224DC                 movb    rl4, #2
8224DE                 movb    asc0_MaxToReceive, rl4
8224E2                 bset    S0RIE
8224E4                 mov     r4, #0FFEFh
8224E8                 and     asc0_Bits, r4
8224EC                 movb    rl4, #13h
8224F0                 movb    asc0_ComMode, rl4 ; 0x1? == McMess
8224F4                 mov     r12, #1
8224F6                 calls   82h, transmitData_s0 ; r12 is len
8224FA
8224FA _mcm_out:                              ; CODE XREF: MCMessSyncroPush+C↑j
8224FA                                         ; MCMessSyncroPush+70↑j ...
8224FA                 mov     r8, [r0+]
8224FC                 mov     r9, [r0+]
8224FE                 rets
8224FE ; End of function MCMessSyncroPush
Logged
fluke9
Full Member
***

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #1 on: October 16, 2019, 02:23:43 PM »

Oh and forgot to mention, ofcourse i set the 9th bit for the request bytes...
Logged
fluke9
Full Member
***

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #2 on: October 16, 2019, 02:59:55 PM »

man, i feel stupid...
and man this protocol sucks...

answering myself: yes, it sees its own answer and therefore tears down the connection,
the solution is to send a request as soon as you see the last answer byte so you overwrite whats in S0RBUF currently...

Which forces you to log every revolution or none at all...
Small patch would make this much more usable as you could trigger every revolution after x ms have been elapsed,
it just should not bail out and tear down everything...
Logged
woj
Hero Member
*****

Karma: +43/-3
Offline Offline

Posts: 500


« Reply #3 on: October 17, 2019, 03:51:20 AM »

I am too lazy to go through your code in detail, and my knowledge about C167 serial communication over k-line was much better several years ago when I also had to go through some unbearable crap to get it working. In any case, these are some fragments of what I think I remember, with k-line there is some weird interaction going on between TX and RX, and it's not only about echoing but also the interrupts. Long story short, these are my sending and receiving procedures I use in my boot code for ST10:

Code:
send_byte:
        mov S0TBUF, r12
send_wait:
        jnb S0RIC.7, send_wait
        bclr S0RIC.7
        bclr S0TIC.7
        rets

receive_byte:
        jnb S0RIC.7, receive_byte
        bclr S0RIC.7         
        movb rl4, S0RBUF     
        rets                 

Not exactly what you would expect after reading the specs... Not sure though if this is what you stumbled across and whether it solves your problem.
Logged
fluke9
Full Member
***

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #4 on: October 17, 2019, 04:55:04 AM »


My send/receive code ages ago looked similar ;-)

Thanks, got it working, mcmess really kicks itself out.
So if you want to use the syncronous crank reading feature you must read every rotation, otherwise you are kicked out because it reads a byte which it sent itself.
And as the databytes it sends itself do not have the 9th bit set (9N2) it will jump out and tear down the connection.

Solution is as i said to send a byte with the 9th bit set as soon as you are done reading the last databyte it sends,
this will overwrite the byte in S0RBUF.

i patched this with a nop and now i can read at my pace.
Next thing is to bump up the table size to something more useful and maybe move the sending routine from the crank to a periodic task like the 2ms task.





Logged
prj
Hero Member
*****

Karma: +1072/-481
Offline Offline

Posts: 6037


« Reply #5 on: October 17, 2019, 10:38:16 AM »

If you're patching shit anyway then why are you bothering with all this bullshit?
Just send a constant stream of data to the port at a very high baud rate. 187500+
Send two sync bytes at the start, so your client knows where the packet starts, job done.

If you want to be more advanced, listen to incoming stuff as well and have two commands - one that sends a list of addresses which are written to RAM and a 2nd one that sends their values.
Like Dynadefine...

I've been doing it this way on all older Porsche and VAG control units.
Logged

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

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #6 on: October 17, 2019, 12:46:05 PM »

If you're patching shit anyway then why are you bothering with all this bullshit?
Because the mcMess routines are all the same in the ME7.1 ME7.3.1 and ME7.6 binarys i disassembled.
Setting up the addresses is already in McMess, works fine, only needs a larger table.

So its like Dynadefine already.

Looks like i can get this done with a few quite simple byte patches,
and as the signatures for the mcmess routines will be the same i can do a fully automated patcher easily.

Thats the plan, so i dont have to patch that shit in manually anymore after it has been done once.


I've been doing it this way on all older Porsche and VAG control units.
Yeah can do, i want something more generic and highspeed McMess is already at 125kbaud and can be done with the shittiest KKL cables i have here.


Logged
prj
Hero Member
*****

Karma: +1072/-481
Offline Offline

Posts: 6037


« Reply #7 on: October 18, 2019, 03:07:12 AM »

FT232 KKL cables happily do 187500 baud and even more. BTDT.

If you're patching the code, as I said, just patch in your own protocol instead of the mcmess.
That can be done fully automated too, and you are free of all restrictions.

But really, to tune the car, readMemoryByAddress is enough, it works on all the ECU's and gives enough sample rate (if you don't try to log the world) to fully tune the car...
Here's Alfa 166 3.2L with SC for example:


All I used was readMemoryByAddress and was able to modify everything that I needed.
« Last Edit: October 18, 2019, 03:10:14 AM by prj » Logged

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

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #8 on: October 18, 2019, 03:51:22 AM »

FT232 KKL cables happily do 187500 baud and even more. BTDT.
Never tried, even 125kbaud is blazingly fast enough.

If you're patching the code, as I said, just patch in your own protocol instead of the mcmess.
That can be done fully automated too, and you are free of all restrictions.
Sure, thinking of replacing the mc mess ;-)
But i would keep the "infrastructure code" around it as it nicely blends in with kwp2000 and co,
Resets everything correctly after the McMess session is done.
So you can establish a KWP2000 session later and is safe to use in one of the tasks at uses the PECC to transfer the data out so you wont
add silly delays to the existing code which might or might not mess things up if you transfer out a lot of data.

Has a decent enough init with the fast init sequence and so on etc etc.


But really, to tune the car, readMemoryByAddress is enough, it works on all the ECU's and gives enough sample rate (if you don't try to log the world) to fully tune the car...

Sure, would/will be enough, but i also like to poke and play around a bit.
Want to do some more asm modding stuff too like using spare outputs for a shiftlight or water/methanol injection and things like that.
Of course i want to do the SC tune later on but this will most likely happen after the SC has been fitted during the winter months.
Meanwhile i will play with the spare ECU on my bench as i have an old megasquirt stim to supply signals.

Here's Alfa 166 3.2L with SC for example:

All I used was readMemoryByAddress and was able to modify everything that I needed.
Nicely done, was getting about the same power/torque curve albeit a bit lower in total (347PS) on my GTV 3.0.

Did you need to retard ignition ?
Had to do nothing there, as there was no knock and it is still going strong after having covered almost 40000km with ignition on the old ME3.7.1 and fueling on a megasquirt.


Logged
prj
Hero Member
*****

Karma: +1072/-481
Offline Offline

Posts: 6037


« Reply #9 on: October 18, 2019, 05:59:29 AM »

Ignition maps needs axis extending and cell by cell tuning.
Throttle control needs adjusting.
On this car returnless system was removed and return was fitted, so the compensation needed to be zeroed out.
FKKVS needs to be cell by cell tuned.
Load limit obviously increased.

Zero patches needed to the code though on this ECU. It all just works if you know what you are doing.

Setting correct lambda has huge influences on power.
Without dyno tough to find.
Logged

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

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #10 on: October 19, 2019, 12:52:23 PM »

Ignition maps needs axis extending and cell by cell tuning.
Throttle control needs adjusting.
On this car returnless system was removed and return was fitted, so the compensation needed to be zeroed out.
FKKVS needs to be cell by cell tuned.
Load limit obviously increased.

Zero patches needed to the code though on this ECU. It all just works if you know what you are doing.

Setting correct lambda has huge influences on power.
Without dyno tough to find.

Thanks for the info !
Was the pump pressure not ok with the returnless system ?

I was running my C30-94 in an 156 2.5 (swapped a 3.0 in) before and fuel supply did not seem to be an issue on the returnless system.
Did use 470cc injectors (from the Z20LET or LEH iirc).





Logged
prj
Hero Member
*****

Karma: +1072/-481
Offline Offline

Posts: 6037


« Reply #11 on: October 21, 2019, 11:14:51 AM »

I don't know, I did not build the car. They brought it how it was and I made it work.
IIRC we had to fix a few bits and bobs, but nothing significant needed changing, it was surprisingly solid.
Logged

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

Karma: +26/-1
Offline Offline

Posts: 113


« Reply #12 on: October 21, 2019, 03:02:34 PM »

Got it running with a few patched bytes,
can happily read a lot of data at 2 x crankspeed (see hz)

Next thing is to wrap it up in a usable and configurable form and do an automated patcher...

« Last Edit: October 21, 2019, 03:08:42 PM by fluke9 » Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.024 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)