M-Drive and MDM in non M cars

[carabuser]

Thanks, that's what I have and maybe would've worked fine if I corrected the coding.

St_mdrv_taster goes to 2 momentarily each time the wheel button is pressed from my logs, _anz (light) goes to 2 while it's on.

View attachment 48154

That makes sense, that means you must have had CW_SPORT_SZL active for it to turn on.

It should latch on

It has rising edge detection so I'd assume that is a one-shot in the logic which means it will be turned off next scan and not self reset until the button is pressed again? So the MDrive steering wheel button should act as a toggle switch which would make sense.

How does the button behave in logs? You press the button once and it turns the dash light on, then press it again and it goes off?

 

[carabuser]

Looking at your log here: https://datazap.me/u/rsl/lc2-stage-3-set-m-button-only?log=0&data=4-10-20-21-23-24-25

That behaves exactly as I'd expect. So all that logic is active and the DME is writing those values. So you're not seeing anything change at the DSC end?

 

[RSL]

That makes sense, that means you must have had CW_SPORT_SZL active for it to turn on.

It should latch on

View attachment 48163

It has rising edge detection so I'd assume that is a one-shot in the logic which means it will be turned off next scan and not self reset until the button is pressed again? So the MDrive steering wheel button should act as a toggle switch which would make sense.

How does the button behave in logs? You press the button once and it turns the dash light on, then press it again and it goes off?

Everything I had set in INA0S, so it should work. I expected it might after I had some activity with the Kombi light. I may try INA0S again tomorrow, but I don't have the addresses to the same params in it.

Yes, Kombi light on/off with wheel button.

Looking at your log here: https://datazap.me/u/rsl/lc2-stage-3-set-m-button-only?log=0&data=4-10-20-21-23-24-25

That behaves exactly as I'd expect. So all that logic is active and the DME is writing those values. So you're not seeing anything change at the DSC end?

DSC goes off with DSC button only, not with wheel button and DSC set off in DME. The CIC changes to show DSC is off with it set in DME and wheel button pressed, but it doesn't actually turn it off.

It's all close, but something either isn't receiving or looking for quite everything, especially the trans/GWS. For sure, RNG_L throttle is active, M Drive EPS steering signal is active, etc. on the wheel button, not quite getting to where they should. I'm more concerned about the DCT part since everything else either works with separate physical buttons or I don't plan to use it at all (servtronic).

 

[carabuser]

That all seems like everything in the DME is working correctly. Forgive me if I'm understanding everything wrong as it's late here and I've been staring at my PC all night but is the only problem currently that the DSC isn't changing state?

With those tables set to 1, toggling the Mdrive button should turn off the DSC,

I'm sure I can make the normal sport button bring on Mdrive so we don't need that extra button but it's only worth doing if we can make things work with the proper hardware to begin with.

 

[aus335iguy]

@RSL what KOMBI coding do you have ? M or Non M?

 

[RSL]

That all seems like everything in the DME is working correctly. Forgive me if I'm understanding everything wrong as it's late here and I've been staring at my PC all night but is the only problem currently that the DSC isn't changing state?

With those tables set to 1, toggling the Mdrive button should turn off the DSC,

I'm sure I can make the normal sport button bring on Mdrive so we don't need that extra button but it's only worth doing if we can make things work with the proper hardware to begin with.

There's probably an issue with M3 DCT bin and how 1M M drive works, but maybe that can be gotten around. DSC doesn't work with the M button, but that's small potatoes since the DSC button itself works. Not at all convinced MDCT is getting anything other than normal prog even though Olza says it does in P5-P6. I've not seen anything in any logs that indicates it and sure don't feel it.

You'd think maybe the DKG enable in the DME might add the bits on 399 for the DCT. Not sure what it does, but maybe not compatible with the M3 bin. My plan was to go back to stock shifter and bin or Z4 bin if we couldn't get this going, and it might work on that since 1M DCT appears would have been same sport button setup, but want to test everything possible on the M3 setup first.

Good place to start for trans might be in finding what exactly that DKG enable in the DME actually does or should do. Other than that, seems like anything internal to DME works fine on the button and signals get sent out that at least reflect on CIC, but doesn't have an effect on the various modules.

Z4 button came in yesterday, but it's too cold to spend an extended time under the dash yet.

@RSL what KOMBI coding do you have ? M or Non M?

M3 right now, but behavior is the same with 1M coding.

 

[amg6975]

Guys, there's a lot of guessing flying around here that's wrong. I posted everything needed in the other thread... The SZL just triggers the DME to set two "M Drive ON" fields in 0x399. One of them, the one that exists in IKM0S and others just turns the light on in the KOMBI. The other is bits 0-1 of Byte 1 and that's what triggers the DSC, JBBF, and DKG to accept the M Drive settings broadcast in 0x399. The KOMBI has absolutely no input to anything M Drive related.

 

[amg6975]

try these... http://www.loopybunny.co.uk/CarPC/k_can.html some of them apply to our cars
the lights and stuff, i believe the kombi is listening for the 0x399 message...


i think @RSL tried playing with them a while ago but it these unfortunately dont touch byte 1 bit0-1
iirc its in one of the xdfs he shared a long while ago

The Power state and DSC state must be separate from 0x399 because they can be activated/deactivated independent from M Drive.

Without getting Byte 1 bit 0-1 working, M Drive setting up the DSC, Servotronic(JBBF,) or Drivelogic(DKG) just isn't going to work. You can get the DME to accept and broadcast settings, get the KOMBI light to turn on, but nothing functional will work.

 

[amg6975]

So another option if the DME software can't be hacked to update Byte 1 bit 0-1 it could be compiled with CW_SPORT_SZL = 0 so that 0x399 is not transmitted, then use an arduino or whatever to transmit 0x399 and trigger the "On" states on the Sport Button press, no SZL needed.

This is why I was asking about the checksum in 0x399. We now have the whole packet 100% figured out which could be implemented easily.

 

[RSL]

Guys, there's a lot of guessing flying around here that's wrong. I posted everything needed in the other thread... The SZL just triggers the DME to set two "M Drive ON" fields in 0x399. One of them, the one that exists in IKM0S and others just turns the light on in the KOMBI. The other is bits 0-1 of Byte 1 and that's what triggers the DSC, JBBF, and DKG to accept the M Drive settings broadcast in 0x399. The KOMBI has absolutely no input to anything M Drive related.

I'm fairly convinced this is it, can't even tell it's missing on MSD81 from the docs and still not clear if it's because 1M is MT production only. If the same logic is in INA0S and others though, curious if/how they differ because INA0S is DCT/MT. Maybe it include the 2 low bits. Am also curious AF what the DCT logic switch actually does in IKM0S if it's not adding them.

I suppose I could kill SZL switch in DME and try broadcasting the full 0x399 and see what happens, but would would need a bit to get a sketch done that actually works with checksum.

 

[aus335iguy]

The Power state and DSC state must be separate from 0x399 because they can be activated/deactivated independent from M Drive.

correct except for M dynamic mode which is only accessible via MDrive

 

[Olza]

Ok we are back to situation which was described long time ago.
I can not see in that screens and docs for MSD81 for initiating that status. More info from docs.

Inputs:
SY_SPORT_SZL should be 1.
CW_SPORT_SZL should be 1.
St_mdrv_taster = STATE_SPT_SWI. This signal goes from MDRIVE Button (see below description of packet), if STATE_SPT_SWI=1, St_mdrv_taster=2 (Active) else 0!
If this conditions meets, Sportschalter/MDrive data combined (see below) and B_sport_szl status triggered.

If we assume that st_ is bits which goes to CAN packet, then there are only outputs from DME of:

St_mdrv_anz = CTR_DISP_MDRV 1:inactive and 2:active [signal for KOMBI].
St_mdrv_dsc = ST_MDRV_DSC [signal for DSC].
St_mdrv_mod_grb = ST_MDRV_MOD_GRB [signal for DCT].
St_mdrv_stg_grb = ST_MDRV_STG_GRB [signal for DCT].

!Not described in docs St_mdrv_eng = ST_MDRV_CHC_ENG 1:Kennlinie1 and 2:Kennlinie2 [signal for DME] ???

Conditions:
B_sport_szl triggers B_sport status - main DME condition when Abgasturbolader, Fahrerwunschmoment and LängsDYNamikFilterung tables switched to sporty.
If SY_SPORT_SZL and CW_SPORT_SZL not TRUE, then B_sport_schalter used for B_sport status - looks like ordinary Sport button.
In my 135 DCT Sportmodus status goes from CAN 0x1D2 GETRIEBEDATEN packet Byte3 bits 2-3. Ive tested situation when Sportmodus did not send via CAN - then engine did not react for sport button. Need to retest.

Check of 0x1D9 Operating buttons M-Drive 0x2 SZL_LWS. Activation: LV_VAR_SPT_SWI = 1

STATE_SPT_SWI = OP_PUBU_MDRV

Conclusion.
Currently we are still can not get correct status in that byte1 bits 0-1, needed for DCT. And also can not find who fills it.
Maybe only M3 program has it? But why in MSD81 dkg_ and dkg_st stored and broadcasted? Maybe there is some other CAN related parameter to enable this.
@RSL can you confirm you are getting real stored values for _dkg and _dkg_st in 0x399 packet when mdrv button pressed? Change them manually to 2 and 6 for example. Who the hell broadcasting 0x399 packet?

UPD. 0x399 Status M-Drive 0x12 DME1. Who can show me CAN routines for this packet?

Also there is 0x3CA Configuration M-Drive 0x62 M_ASK/CCC_GW - DME should read this and store inside updated config from user UI. If so, E82 M configuration is constant and transfers when M-button pressed. In M3 it has been updated somehow after CCC user change.

 

[carabuser]

Guys, there's a lot of guessing flying around here that's wrong. I posted everything needed in the other thread... The SZL just triggers the DME to set two "M Drive ON" fields in 0x399. One of them, the one that exists in IKM0S and others just turns the light on in the KOMBI. The other is bits 0-1 of Byte 1 and that's what triggers the DSC, JBBF, and DKG to accept the M Drive settings broadcast in 0x399. The KOMBI has absolutely no input to anything M Drive related.

It will be possible to hack that bit to be on but at the moment I don't understand enough about how the CAN packet is created inside the DME. I have all the logic set out for the data in the packet and I can see where the DME does the CAN transmission, I can see the checksum creation, the alive counter increment and also the part of the logic that decides how large the data packet is going to be but I just can't yet see where the packet data is stored in RAM.

@RSL I checked the logic between IKM0S and INA0S and there's no difference, IKM0S has nothing extra.

 

[AzNdevil]

It will be possible to hack that bit to be on but at the moment I don't understand enough about how the CAN packet is created inside the DME. I have all the logic set out for the data in the packet and I can see where the DME does the CAN transmission, I can see the checksum creation, the alive counter increment and also the part of the logic that decides how large the data packet is going to be but I just can't yet see where the packet data is stored in RAM.

@RSL I checked the logic between IKM0S and INA0S and there's no difference, IKM0S has nothing extra.

dont think its stored in ram
its put together using the st_mdrv_* stuff which is stored in ram then gets sent out whenever c_can_st_mdrv is called

 

[carabuser]

dont think its stored in ram
its put together using the st_mdrv_* stuff which is stored in ram then gets sent out whenever c_can_st_mdrv is called

This is where I think the packet is built:

My assumption would be that you just specify a start address in memory for a transmission then a length, that's how every data transfer I've ever done has worked but I don't work with cars. Those ST_MDRV_ signals are all contiguous in RAM so I would expect them to follow the structure of the 0x399 packet with CHKSM_ST_MDRV being at the end but that's not the case.

This is the RAM area for the ST_MDRV_ tags:

And the RAM area for the state_spt_ tags that ST_MDRV_ are mapped into before CAN transmission:

Just doesn't make sense to me.

@Olza Do you have any idea how CAN data is structure from looking through the DCT?

 

[Olza]

Yes, but where is reading from calibration data C_SPORT_MDRV_DKG for example?
strange, that broadcasted state_spt_ and not St_mdrv_...
I see it like DME reads them as default, then loaded to LDRAM variables like state_spt_mod_gb. big possibility that they stored and changed in CIC, then broadcasted to DME. Can you find 0x3CA Configuration M-Drive packet parsing in DME? if im right, there will be parsing values for state_spt_...

And NO filling our mystical byte1 bits 0-1.
@carabuser , sure i can see in DCT:

Only ST_MDRV_MOD_GRB, ST_MDRV_STG_GRB and that activation parameter reading from incoming packet (extr 8,2 means byte 1 offset and low two bits).
It ends what MSD81 didnt fills that parameter in own packet... M3 should. But i can patch program to test as we are thinking to use CTR_DISP_MDRV for activation.

 

[AzNdevil]

This is where I think the packet is built:

My assumption would be that you just specify a start address in memory for a transmission then a length, that's how every data transfer I've ever done has worked but I don't work with cars. Those ST_MDRV_ signals are all contiguous in RAM so I would expect them to follow the structure of the 0x399 packet with CHKSM_ST_MDRV being at the end but that's not the case.

This is the RAM area for the ST_MDRV_ tags:


And the RAM area for the state_spt_ tags that ST_MDRV_ are mapped into before CAN transmission:

Just doesn't make sense to me.

@Olza Do you have any idea how CAN data is structure from looking through the DCT?

let me try to explain this... i am not good at explaining stuff thought so forgive me if i get this wrong
i used ghidra to decompile this and it doesnt do it cleanly

take this as an example
800f2062 puts together the address of the can message buffer to a12 as a pointer
800f206a stores the address into d15

800f206c directly writes 0xffff to the can message buffer (d15)
800f2074 shifts another 0xffff into the can message buffer (d15)
800f2078 buffer pointer + 4 (byte5) = d15

everything in the middle is done similarly with bit shifting. checksum is calculated then the buffer is sent out to COM_MM_EV_SendMsg at 800f21c8

the gearbox canbus stuff is put together in c_can_GETRIEBEDATEN, c_can_GETRIEBEDATEN_2, c_can_GETRIEBEDATEN_3

 

[AzNdevil]

Yes, but where is reading from calibration data C_SPORT_MDRV_DKG for example?
strange, that broadcasted state_spt_ and not St_mdrv_...
I see it like DME reads them as default, then loaded to LDRAM variables like state_spt_mod_gb. big possibility that they stored and changed in CIC, then broadcasted to DME. Can you find 0x3CA Configuration M-Drive packet parsing in DME? if im right, there will be parsing values for state_spt_...

And NO filling our mystical byte1 bits 0-1.
@carabuser , sure i can see in DCT:
View attachment 48191

Only ST_MDRV_MOD_GRB, ST_MDRV_STG_GRB and that activation parameter reading from incoming packet (extr 8,2 means byte 1 offset and low two bits).
It ends what MSD81 didnt fills that parameter in own packet... M3 should. But i can patch program to test as we are thinking to use CTR_DISP_MDRV for activation.

state_spt_* is copied from St_mdrv_*

 

[Olza]

Can you find 0x3CA Configuration M-Drive packet parsing in DME? if im right, there will be parsing values for state_spt_...

so yes, filling of that any values from 0x3CA

 

[carabuser]

so yes, filling of that any values from 0x3CA

I searched for 0x3CA but no results for a CAN packet.