M-Drive and MDM in non M cars

RSL

Lieutenant
Aug 11, 2017
937
501
0
No DCT/AT I'm 6MT.
IKM0S on MSD81.
Stock DSC or MDSC.
JBE coded for FDS

Ground Pin 18 on X14271 for Sport and 36 for Normal.
Check status in Tool32 -> MSD80 -> status_spt. STAT_STAT_SPT will change to 1.

It does the same thing 1D9 does but doesn't broadcast 399 so you never get an M light on Kombi.
It does change vehicle mode 0x315. See https://github.com/AdrianBude/N54-Mdrive-MCP/blob/master/traces/trace 315.txt

On the Z4 Kombi you'll see Normal, Sport, Sport+. You should also get a popup on Z4 CIC if FDS is coded.



I doubt this will be useful to most people. It would be really cool for my sketch to display the popup on CIC but that's about it. I can already trigger the sport mode with M drive.
MT, ok. Were both pins empty in the JBBF connector?

Others want other things, but my goal was getting the MSD81 side stuff talking with M3 GWS/EGS. Other things seem to work on M drive button, but doesn't seem to be any outside signal that trans will respond to so far.

We now know the 0x399 message differs between M3 and 1M/non-M thanks to amg and @Olza. Byte 1 bits 0-1 are noted as unused in MSD81 docs, but those are ones responsible for allowing settings data to the trans. That's what today's test was, I added that to the message, but still seems no joy yet. CIC reflects whatever I set with it, but that's it. Perhaps there's still a piece we're missing.

Thanks for that Tool32 ID. I've been using other things to try to monitor program state for trans, but with lack of comms, can't really trust anything. I'll give that a shot.

The M3 bin does specifically look for 0x315 for mode, but amg says his doesn't do anything in an actual M3, so I'm not sure what to make of that. Since it's active on Z4 setup, M3 bin might respond to it anyway with a program change, but I'll exhaust all options on the current train before trying it.

After I started looking at it more closely in last 2 weeks, I did notice there were DSC wiring differences on Z4. If it's just a matter of loosening controls, I'm less worried about it, but if it's a requirement to make program change work at all (doesn't sound like it is), will make it a little more work.
 

aus335iguy

Colonel
Nov 18, 2017
2,256
806
0
Down under
Ride
335i DCT 2009
Do we have such documentation for m3 dme? Simple check can description.
 

Olza

Corporal
Feb 2, 2020
232
234
0
Minsk, Belarus
Ride
BMW 320d
Woohoo! MSS60+ used as twice more information! We definitely need to emualte ST_MDRV. @RSL are you sure you correctly emulate 0x399 packet?
1611072529646.png

1611072556639.png


Also ST_MDRV_SRST interesting...

1611072913102.png


Short investigation. Missed:

ST_MDRV !!! 2 bits - byte1 low two bits !!!
ST_MDRV_SRST - byte5 low 3 bits
ST_MDRV_EPAS - byte4 high two bits
ST_MDRV_DISP_HUD - byte4 low four bits
ST_MDRV_CHC_ALBV and ST_MDRV_EDCK - byte3 high and low 4 bits
ST_MDRV_DISP_SHLI 3 bits - definitely byte5, but there is misunderstanding in docs with bit-size i guess...
 
  • Like
Reactions: AzNdevil

superwofy

Corporal
Jan 18, 2021
130
194
0
I think ST_MDRV_SRST is the reset to default option. How it gets set from CCC/CIC -> kcan -> JBE -> PT-CAN -> MSS6X would be interesting.
 
  • Like
Reactions: aus335iguy

AzNdevil

Lieutenant
Staff member
Nov 4, 2016
602
286
0
Hong Kong
Woohoo! MSS60+ used as twice more information! We definitely need to emualte ST_MDRV. @RSL are you sure you correctly emulate 0x399 packet?
View attachment 48304
View attachment 48305

Also ST_MDRV_SRST interesting...

View attachment 48306

Short investigation. Missed:

ST_MDRV !!! 2 bits - byte1 low two bits !!!
ST_MDRV_SRST - byte5 low 3 bits
ST_MDRV_EPAS - byte4 high two bits
ST_MDRV_DISP_HUD - byte4 low four bits
ST_MDRV_CHC_ALBV and ST_MDRV_EDCK - byte3 high and low 4 bits
ST_MDRV_DISP_SHLI 3 bits - definitely byte5, but there is misunderstanding in docs with bit-size i guess...

wow that was fast, you actually read through everything lol

@

@amg6975 can hopefully and finally solve that mystery for everyone soon
This will also help the M3 peeps who want to diy retrofit mdrive

mdrive retrofit? i thought only sport szl replacement is required? at least thats what i saw on some m3 forum..
 

RSL

Lieutenant
Aug 11, 2017
937
501
0
Woohoo! MSS60+ used as twice more information! We definitely need to emualte ST_MDRV. @RSL are you sure you correctly emulate 0x399 packet?
View attachment 48304
View attachment 48305

Also ST_MDRV_SRST interesting...

View attachment 48306

Short investigation. Missed:

ST_MDRV !!! 2 bits - byte1 low two bits !!!
ST_MDRV_SRST - byte5 low 3 bits
ST_MDRV_EPAS - byte4 high two bits
ST_MDRV_DISP_HUD - byte4 low four bits
ST_MDRV_CHC_ALBV and ST_MDRV_EDCK - byte3 high and low 4 bits
ST_MDRV_DISP_SHLI 3 bits - definitely byte5, but there is misunderstanding in docs with bit-size i guess...
I *think* so. Since I'm focusing on trying to get it talk to M3 GWS/trans, I completely ignored MSD Mdrive message layout and used the real M3 one @amg6975 posted.
 
  • Like
Reactions: aus335iguy

aus335iguy

Colonel
Nov 18, 2017
2,256
806
0
Down under
Ride
335i DCT 2009
mdrive retrofit? i thought only sport szl replacement is required? at least thats what i saw on some m3 forum..
Apparently not. https://www.spoolstreet.com/threads/coding-m-modules-in-a-non-m-car.6190/post-101678
Im still not sure why his didnt work, Im also not convinced that the SZL is required. Tom from brintech once explained that any SZL will work with the M3DSC it just takes some special sauce to make it work .

edit heres the post
 

AzNdevil

Lieutenant
Staff member
Nov 4, 2016
602
286
0
Hong Kong
Apparently not. https://www.spoolstreet.com/threads/coding-m-modules-in-a-non-m-car.6190/post-101678
Im still not sure why his didnt work, Im also not convinced that the SZL is required. Tom from brintech once explained that any SZL will work with the M3DSC it just takes some special sauce to make it work .

edit heres the post
iirc in one of the earlier threads i posted...someone said the same thing....and it seems the button behaviour is different altogether in different generations of m3
my question is... does holding down the mdrive button really activate mdm?

and theres this....
1611077832444.png
 

aus335iguy

Colonel
Nov 18, 2017
2,256
806
0
Down under
Ride
335i DCT 2009
iirc in one of the earlier threads i posted...someone said the same thing....and it seems the button behaviour is different altogether in different generations of m3
my question is... does holding down the mdrive button really activate mdm?
Well thats what people say.... but yeah ?

Im not sure what this means ....
 

amg6975

Sergeant
Oct 27, 2019
278
187
0
Ride
2012 135, 2005 ZHP, 2009 fJCW
Wish @amg6975 was here. He's probably working on his 1er. The canbus captures would probably shed a lot of light on things
Ta da. Took the early shift with the baby today. What's the question?

EDIT: Oh, lookie what Olza found. Give me a minute to digest it and I'll write up what I know.
 
  • Like
Reactions: aus335iguy

amg6975

Sergeant
Oct 27, 2019
278
187
0
Ride
2012 135, 2005 ZHP, 2009 fJCW
Woohoo! MSS60+ used as twice more information! We definitely need to emualte ST_MDRV. @RSL are you sure you correctly emulate 0x399 packet?
View attachment 48304
View attachment 48305

Short investigation. Missed:

ST_MDRV !!! 2 bits - byte1 low two bits !!!
ST_MDRV_SRST - byte5 low 3 bits
ST_MDRV_EPAS - byte4 high two bits
ST_MDRV_DISP_HUD - byte4 low four bits
ST_MDRV_CHC_ALBV and ST_MDRV_EDCK - byte3 high and low 4 bits
ST_MDRV_DISP_SHLI 3 bits - definitely byte5, but there is misunderstanding in docs with bit-size i guess...

Ok so my M3 doesn't have EDC or HUD so I didn't see those change.

ST_MDRV is what I've been saying is the issue with non-M cars. This definitely what triggers everything to adopt M Drive settings or revert back. 0b01 = enabled 0b10 = disabled.

ST_MDRV_SRST in my log is always 0b111 which is invalid. Its options are:
  • 0b000 = No Configuration Mode
  • 0b001 = Data Accepted
  • 0b010 = Default Transmitted
  • 0b100 = Reset Takes Place
  • 0b111 = Signal Invalid
I'm thinking maybe this is a return status to tell the iDrive if the DME has accepted it's settings or what. I did look at 0x399 when updating the iDrive settings but don't remember this changing, and it's too late to check now. This would make sense since 0x3CA is only transmitted once when the settings were accepted in iDrive which seems sketchy at best. The way CAN works is priority is set by the ARBID and lower ARBIDs can abort higher ARBID transmissions and take over the bus. 0x3CA is a pretty low priority and BMW would absolutely not risk settings not sticking when the user tries to apply them. So, I think it's something like:

- CIC sends 0x3CA with updated settings then the DME sends 0x399 with ST_MDRV_SRST with "Data Accepted" or whatever.

My second theory is this is status' for if there is no iDrive.

ST_MDRV_CHC_ALBV has to do with the backrest width... I had no idea this could be saved in M Drive. Mine was always 0b0010.

ST_MDRV_EDCK was always 0b0010 but again, no EDC so I suspect Comfort is just the default.

ST_MDRV_DISP_HUD was always 0b0001 or, but no HUD so it seems the default is on.

Everything else I've already documented where it is in 0x399 and what it does.

I think ST_MDRV_SRST is the reset to default option. How it gets set from CCC/CIC -> kcan -> JBE -> PT-CAN -> MSS6X would be interesting.

I don't think so. It doesn't change when M Drive is enabled or disabled. The JBBF just copy/pastes messages from K-CAN to PT-CAN. It doesn't modify anything in the packet. See above, CIC sends the iDrive settings in 0x3CA, JBBF passes this onto PT-CAN, MSS60 updates its settings, and possibly sets the ST_MDRV_SRST to tell the CIC that it's accepted or rejected the settings.

@Olza can you see in the DKG if it does anything with ST_MDRV_SRST?