GS7 program code disassembly project

[amg6975]

That'd be my guess as well, oil viscosity and how the clutches engage/disengage based on RPM.

@Olza have you been able to sniff out the GWS commands to the TCU? I have a custom board mimicking/controlling GWS functions for the 135/335 now so converting that to M3 transmission commands would be trivial. Then, if we can't get this flash going, the swap wouldn't require a GWS change. My hope would be to stick the board between the TCU and the PT-CAN and I think I could eliminate the need for the diff change too, if the CAN shifting back-and-forth works how I think it does. The unit would be installed in the bin under the hood, like a JB4.

Specifically I'm interested in 0x198 and 0x4DE. I'm also really curious if anyone knows the source of the sport mode status on the 135/335. The button presses are in 0x198 byte 4, but something is telling the footwell module to turn the indicator light on/off and I doubt it's just doing it blindly based on button presses.

 

[Olza]

first, there is a parameter in M3 program which controls using ordinary or m3 gws. and many more interesting parameters... its a pity we still can not rewrite modified data
second, at this moment i can see only how TCU parses bits in CAN packets. besides, LIN interchange used and i do not know how TCU will interprete fake GWS and empty LIN data. we should try.
it seems 0x4DE is not used by TCU.

about incoming 0x198.
0 byte: ppppxxxx
where four higher BITS (pppp) of first byte represents m3 stick position/move - 0000xxxx, 0001xxxx [R], 0010xxxx [SHIFT LEFT], 0011xxxx [D/S], 0100xxxx [M-], 0101xxxx [M+] and 0110xxxx [M?], xxxx is packet sync counter
1 byte: ddddkkkk
where kkkk =1111 XOR pppp (crc like), dddd is 335 stick position/move you know which one
2 byte: kkaakkkk
where kkkk =1111 XOR dddd (crc like - can not be 0x00, dddd can not be 0x0F), aa - param1 (all params can not be 0x03!), kk is just xor crc aa
3 byte: kkddccbb
bb - 335 ParkButton, cc - 335 ParkButton mirror, dd - 335 SideButton, kk is just xor crc dd
4 byte: 11ggffee
ee - param5, ff - 335 SPORT, gg - M3 POWER (?)
5 byte: 11111111

 

[Olza]

@amg6975 do you have m3 Gws packets logs? It seems we need to recheck m3 stick positions in byte 0, and still unknown are param1 (important because has crc) and param5.

 

[amg6975]

I don't have an M3 GWS so I don't have logs for it, no. If someone wants to send me one to test I'd be more than happy to work it out then send it back to them. The 135/335 GWS is something like this:

Byte0: 0xFx where x counts from 0 to F every 30ms
Byte1: shifter position
Byte2: shifter position "CRC"
Byte3: P/Side buttons
Byte4: Sport Button

0x4DE comes from the GWS... I think this is for error codes and stuff, the only thing I've ever seen is that Byte1 changes based on if the engine is on or off. I was just curious if the TCU looked at it.

I don't see any changes for anything in param1 or param5 in 135/335 data, the upper nib of Byte 2 stays at 0b1100 and 'ee' stays at 0b00.

I think the LIN bus is used as a fail-safe if the CAN bus fails. I didn't use it in my controller and there are no error messages. I also just let the TCU handle the park solenoid and it seems plenty happy about it. I can successfully fake the GWS with just the WKUP, CAN+ and CAN- without any errors... so far.

 

[Olza]

I don't have an M3 GWS so I don't have logs for it, no. If someone wants to send me one to test I'd be more than happy to work it out then send it back to them. The 135/335 GWS is something like this:

Byte0: 0xFx where x counts from 0 to F every 30ms
Byte1: shifter position
Byte2: shifter position "CRC"
Byte3: P/Side buttons
Byte4: Sport Button

0x4DE comes from the GWS... I think this is for error codes and stuff, the only thing I've ever seen is that Byte1 changes based on if the engine is on or off. I was just curious if the TCU looked at it.

I don't see any changes for anything in param1 or param5 in 135/335 data, the upper nib of Byte 2 stays at 0b1100 and 'ee' stays at 0b00.

I think the LIN bus is used as a fail-safe if the CAN bus fails. I didn't use it in my controller and there are no error messages. I also just let the TCU handle the park solenoid and it seems plenty happy about it. I can successfully fake the GWS with just the WKUP, CAN+ and CAN- without any errors... so far.

ok now. my description is completely reflects your findings. so in M3 gws that second 4 bits in 0xFx will be shifter position (in 335 they are always 1111xxxx so 0xFx) thats what we should test.

 

[amg6975]

ok now. my description is completely reflects your findings. so in M3 gws that second 4 bits in 0xFx will be shifter position (in 335 they are always 1111xxxx so 0xFx) thats what we should test.

Yeah, I think you're findings are correct based on where I don't see dynamic data in the 135/335 system. It makes sense they would be separated in the packet. That means that if we can make an interposer unit I could auto detect if the car had a 135 or 335 GWS and adjust the outputs appropriately.

Here's the next question: When the TCU wants to shift it sends a torque request to the ECU, shifts, then releases the ECU to normal operation. What does the TCU use to determine it's done with a shift and it's ok to release the ECU? I know it has to be related to vehicle speed, but is it from the internal output shaft speed sensor, or something on the CAN? I can see the transmission output shaft speed on the CAN so it definitely has it, I'm just hoping that's not what it uses to know the shift is complete.

 

[aus335iguy]

I have an M3 GWS and can send it. @jyamona might have some insight into what the DME sees.
With respect to what the tcu useds to determine a shift is completed
This is purely speculative but my theory is...

• The tcu knows engine revs from DME,
• we know the gearbox has two sensors for post clutch shaft speed(one for each gearbox)
• it knows gear position and knows output revs.

In other words it can ‘see’ the delta between engine rpm and post clutch rpm. If a delta exisits, clutch is disengaged or slipping. Perhaps tcu reports tbe delta ?

 

[doublespaces]

I don't have an M3 GWS so I don't have logs for it, no. If someone wants to send me one to test I'd be more than happy to work it out then send it back to them.

I also have an M3 GWS, I live in AZ if that is closer than Australia.

 

[derekgates]

Damn, I am about to install my M3 GWS in the next few weeks... could have sent it off while it sat on a shelf in my garage! :doh:

 

[amg6975]

@jyamona might have some insight into what the DME sees.
With respect to what the tcu useds to determine a shift is completed
This is purely speculative but my theory is...

• The tcu knows engine revs from DME,
• we know the gearbox has two sensors for post clutch shaft speed(one for each gearbox)
• it knows gear position and knows output revs.

In other words it can ‘see’ the delta between engine rpm and post clutch rpm. If a delta exisits, clutch is disengaged or slipping. Perhaps tcu reports tbe delta ?

What I'm worried about is how does the TCU know when the rev match has been completed, through it's own output shaft speed, or from the vehicle speed from the DCS. If it uses the DCS speed then I can spoof it, if it uses it's output shaft speed, I can't.

The process is basically:

1. You request a shift
2. The TCU decides if it needs to rev match up or rev match down
3. Sends a torque demand to the ECU, either increase or decrease
4. Opens the clutch/does its DCT magic
5. Once the revs match the rev target it releases/switches the clutch (which is based on gear ratios and final drive)
6. Tells the ECU to resume normal operation

What I'm curious about is how does it know when step 5 is done.

I'm in NY, if anyone wants to send me an M3 GWS. AZ sounds a lot better than Australia. I should only need it for a couple days and I can send it right back.

Adam

 

[aus335iguy]

You’d have to look at the m dct document here somewhere to confirm but my understanding is that the TCU measures both gearbox shaft speeds post clutch and receives the input revs from the engine. It therefore knows the amount of slip from each clutch and the wheel speed. I can’t see why it would need the DSC road speed since it knows which gear and how fast that gear is rotating.

I could be wrong but....I’m probably wrong. Wedo need to find out though

 

[amg6975]

You’d have to look at the m dct document here somewhere to confirm but my understanding is that the TCU measures both gearbox shaft speeds post clutch and receives the input revs from the engine. It therefore knows the amount of slip from each clutch and the wheel speed. I can’t see why it would need the DSC road speed since it knows which gear and how fast that gear is rotating.

I could be wrong but....I’m probably wrong. Wedo need to find out though

Yes, the trans could operate stand along if it wanted to. It has input shaft speed (RPM) both jack shaft speeds and output shaft speed. But, the DSC outputs all four wheel speeds, the "vehicle speed," and the KOMBI outputs the "display speed." There's a TON of speed info flying around the CAN, so who knows what BMW uses... but my gut says you're probably right and it uses output shaft speed, as that's what it's ultimate trying to match.

 

[aus335iguy]

Yes, the trans could operate stand along if it wanted to. It has input shaft speed (RPM) both jack shaft speeds and output shaft speed. But, the DSC outputs all four wheel speeds, the "vehicle speed," and the KOMBI outputs the "display speed." There's a TON of speed info flying around the CAN, so who knows what BMW uses... but my gut says you're probably right and it uses output shaft speed, as that's what it's ultimate trying to match.

Thinking about it again; i must be wrong, it can’t be the case. That means that the TCU would shift flawlessly regardless of final drive. It MUST use wheel speed as well.....

 

[doublespaces]

I skipped the last few replies but I can say that with a mechanical device you can spoof the wheel speed. Maxxecu managed to bypass the diff ratio issue this way before the TCU was cracked, apparently the message just needs sent rapidly enough to over ride whatever other signal it's receiving.

 

[aus335iguy]

You've been holding out on us !!!! Mechanical as in change the wheel sensor speed ring or a wheel speed corrector device( Yellow box)?
.... so a wheel speed interceptor on the can bus right before the TCU will work and m3 flash is possible with just this and the m3 GWS. If @amg6975 manages to spoof the GWS.....
At that point we would still have to work on shift pressure(make sure its appropriate for n54 on an M3 tune ) and non m3 KOMBI, SZL integration but the car would drive as you would want. No telling how many errors there would be though

 

[doublespaces]

Sorry I mean physical hardware aka it's done with their standalone

Edit: also I can't recall exactly but take wheel speed with grain of salt. I can't remember the specifics but I know a signal can be faked and this issue overcome.

 

[aus335iguy]

Was that in a car retrofitted with a dct ?
In our cars there are more modules that might rely on that message. KOMBI and DSC specifically. the same thing can be applied but it needs to be done only on the TCU

edit: I’m purely speculating here

 

[Olza]

there is an option in data calibration defining source of wheelspeed. default is 0 - get speed from CAN ID 0x0CE individually, else calculate mean from final drive, wheels and output shaft speed. formulae i posted somewhere above in threads.

 

[Begood69]

What I'm worried about is how does the TCU know when the rev match has been completed, through it's own output shaft speed, or from the vehicle speed from the DCS. If it uses the DCS speed then I can spoof it, if it uses it's output shaft speed, I can't.

The process is basically:

1. You request a shift
2. The TCU decides if it needs to rev match up or rev match down
3. Sends a torque demand to the ECU, either increase or decrease
4. Opens the clutch/does its DCT magic
5. Once the revs match the rev target it releases/switches the clutch (which is based on gear ratios and final drive)
6. Tells the ECU to resume normal operation

What I'm curious about is how does it know when step 5 is done.

I'm in NY, if anyone wants to send me an M3 GWS. AZ sounds a lot better than Australia. I should only need it for a couple days and I can send it right back.

Adam

I have one extra i can send to u. Pm me an address. (Extra parts) cable for parking brake was cut.
And when done send it back.

 

[amg6975]

I skipped the last few replies but I can say that with a mechanical device you can spoof the wheel speed. Maxxecu managed to bypass the diff ratio issue this way before the TCU was cracked, apparently the message just needs sent rapidly enough to over ride whatever other signal it's receiving.

This was my first thought, but I don't think this is necessary, and is a total hack. This is how I was planning on doing it when I thought the TCU sent the ECU a target RPM, but it doesn't, it basically just hijacks the ECU's throttle output so the TCU controls the throttle during shifts. I don't think we need to mess with that, we just need to correct when the TCU thinks all the speeds match up.

Was that in a car retrofitted with a dct ?
In our cars there are more modules that might rely on that message. KOMBI and DSC specifically. the same thing can be applied but it needs to be done only on the TCU

edit: I’m purely speculating here

No, the individual wheel speeds are not used anywhere else I know of. The DSC sends a "distance since last transmission" packet which the KOMBI uses to calculate MPG, trip, odometer, and speed. The KOMBI then outputs "display speed" which is the actual speed with a offset factor to ensure the speedo is always just a bit fast. All other speed data comes from the DSC. The JBF passes these between the PT-CAN and K-CAN but doesn't actually do anything with them. I'm not sure if the ECU uses speed for anything, and if it does, which one it uses.

Also the way the CAN is implemented, we can put a module between the TCU and the other modules pretty easily.

there is an option in data calibration defining source of wheelspeed. default is 0 - get speed from CAN ID 0x0CE individually, else calculate mean from final drive, wheels and output shaft speed. formulae i posted somewhere above in threads.

This is exactly what I figured since a) there's no other reason this would be on the CAN bus and b) the TCU would want to know if the rears were locked up, or spinning or something. This is also great news for an interposer board since I can just read those, apply an offset and transmit to the TCU, just like I would with the GWS commands. This idea has some real legs now... I have ideas.

Is there a way to switch them on the fly? If we could send a command to switch these without actually changing the software we could do that and try out the second method. The before and after speed would both have the final drive ratio and should essentially cancel out.