TCU sends RPM limit also. even two limits, second one forced RPM when gearbox overheating.
GS7 program code disassembly project
- Thread starter Olza
- Start date
I created a dbc https://github.com/dzid26/opendbc-BMW-E8x-E9x/blob/master/bmw_e9x_e8x.dbc for BMW. All the CANs messages are in a single dbc since the same messages appear in multiple buses.
(You can see the CANbus log after logging in with google. Also it will expire from the server after 2 weeks.)
I put up the opendbc repo to automatically pull signals database for my other project (i.e. integrate Comma's level 2 autonomy to E82/E90).
If anyone has anything to add, I would encourage you to fork my repo and I will be happy to do pull request.
(You don't have to use Cabana web editor, there are free softwares to edit dbc such a kvaser editor)
0001 = N|R;
0010 = R;
0011 = N|D;
0100 = D;
0101 = -1;
0110 = +1;
0111 = ManualMode;
1000 = inBetween;
@amg6975 Btw, the counter goes only 0 to E not F. To be honest, I am not sure if you need such detail of the signal, if your device would only need to scale wheel speed signals and copy all the others. But anyway, if you happen to have Sport button state or shift lever state (PRND) and actual gears, you could add it to database, as they are missing and they could be useful.
@amg6975 @aus335iguy You were wondering about how transmission knows when to finish the shift. I know the answer to common questions as I worked on a few autos and DCT control software.
Normally control looks at gear slip calculated from output shaft speed sensor and input shaft speed sensor. The input sensor on many transmissions is not present and instead engine speed from CAN is used (which adds annoying aliasing and ~20ms delay), but the output sensor was not removed before due to safety and would be too imprecise due to output shaft dynamic flex.
The reason the transmission fails the shifting with the different final drive is likely due to cross-correlation diagnostics of the input signals. If the sensor failure is suspected, another signal can is used (wheel speed in this case).
@Olza it would be great if you could create a repository with instructions of software used, files and settings kept in a single place with a spirit of open-source! It would allow for issue tracking and collaboration. This stuff is already hard to pickup by new people. Only few that worked on it for manufacturers or tuners know even where to start. I would like to learn how to get to the point where you are.
Regarding the RSA key. The TC1766 doesn't have hardcore secure element (HSM), but it still has some protections 7.2.7. Am I right to think that the full dump will not be possible due to these?
We used to have DLL file with protection routines for flashing ZF's (also Tricore) TCU. I would imagine that they would even have different keys for different customers. Similar could be with Getrag.
(You can see the CANbus log after logging in with google. Also it will expire from the server after 2 weeks.)
I put up the opendbc repo to automatically pull signals database for my other project (i.e. integrate Comma's level 2 autonomy to E82/E90).
If anyone has anything to add, I would encourage you to fork my repo and I will be happy to do pull request.
(You don't have to use Cabana web editor, there are free softwares to edit dbc such a kvaser editor)
From my experiment, the shifter position didn't match exactly what was proposed earlier]. Perhaps M3 is slightly different than my 135i.
0001 = N|R;
0010 = R;
0011 = N|D;
0100 = D;
0101 = -1;
0110 = +1;
0111 = ManualMode;
1000 = inBetween;
@amg6975 Btw, the counter goes only 0 to E not F. To be honest, I am not sure if you need such detail of the signal, if your device would only need to scale wheel speed signals and copy all the others. But anyway, if you happen to have Sport button state or shift lever state (PRND) and actual gears, you could add it to database, as they are missing and they could be useful.
@amg6975 @aus335iguy You were wondering about how transmission knows when to finish the shift. I know the answer to common questions as I worked on a few autos and DCT control software.
Normally control looks at gear slip calculated from output shaft speed sensor and input shaft speed sensor. The input sensor on many transmissions is not present and instead engine speed from CAN is used (which adds annoying aliasing and ~20ms delay), but the output sensor was not removed before due to safety and would be too imprecise due to output shaft dynamic flex.
The reason the transmission fails the shifting with the different final drive is likely due to cross-correlation diagnostics of the input signals. If the sensor failure is suspected, another signal can is used (wheel speed in this case).
@Olza it would be great if you could create a repository with instructions of software used, files and settings kept in a single place with a spirit of open-source! It would allow for issue tracking and collaboration. This stuff is already hard to pickup by new people. Only few that worked on it for manufacturers or tuners know even where to start. I would like to learn how to get to the point where you are.
Regarding the RSA key. The TC1766 doesn't have hardcore secure element (HSM), but it still has some protections 7.2.7. Am I right to think that the full dump will not be possible due to these?
We used to have DLL file with protection routines for flashing ZF's (also Tricore) TCU. I would imagine that they would even have different keys for different customers. Similar could be with Getrag.
I take it that's a no then?
I think the hardest thing about getting a full dump of this controller will be getting to the pins needed for boot mode or DAP/JTAG because the bare die is on a ceramic board covered in silicone.
The authentication routines for flashing are no big deal. I have the private keys for that, I assume a lot of other people do too. The code signing keys are the real issue.
no problem. see attach. feel free to ask questions, maybe in private.
now i am focused on TCU logic. also that shift times and how it determines end of shift really in the code. will post results later.
yeah, as i said:
1 byte: ddddkkkk where kkkk =1111 XOR pppp (crc like), dddd is 335 stick position/move you know which one
interesting areas are:
- any of pflash sector, especially 7.
- bootstrap and loader 0xD400 0000 - 0xD400 1FFF !!!
- cached boot 0x8FFF C000 - 0x8FFF FFFF
Last edited:
That's correct, the M3 GWS is different from the 135/335. They use different nibbles of Byte 1 and 2. I think the values you have listed look correct for the upper nibble of byte 1. The lower is 0 for the 135/335. The 135/335 also use the lower nib of byte 2, which is just a bit flip of the upper nib of byte 1. The upper nib of byte 2 is 0xC for the 135/335.
The other important thing to note when spoofing the GWS is you also need to transmit 0x4DE every 500ms as follows:
when the car is on: 0x00, 0x42, 0xFD, 0x01, 0xFF, 0xFF, 0xFF, 0xFF
when the car is off: 0x00, 0x52, 0xFD, 0x01, 0xFF, 0xFF, 0xFF, 0xFF
This is the status of the GWS, I haven't sniffed out all the error states and stuff, but this is "normal operation." I think things like the "press side button" warning and things like that are communicated in this packet, but I automate all that so there's no need for me to transmit anything other than "all good."
Yeah, that's right, it never gets to 0xFF. Strange, it never threw an error for that... if I purposefully threw the count off or stopped the count it would throw a GWS error.
The sport button is sent in bit 2 of byte 4 in packet 0x198. 1 = pushed 0 = not pushed. I have no idea where "sport mode status" is, I've been looking everywhere for it. It must be on the CAN because the FRM turns the Sport Mode light on and off so it has to know the status... I can't imagine it's open loop on/off when the button is pressed, way too much risk of it being out of sync with the actual sport mode.
| Sport Button | 0x198 | GWS | D4: 240 = Not Pressed 244 = Pressed |
PNRDSM and gears are as follows:
| Gear Position | 0x0BA | DKG | D1: 255 = N, 91 = R, 97 = 1, 62 = 2, 44 = 3, 34 = 4, 28 = 5, 24 = 6, 20 = 7 |
| N/D/R | 0x0BA | DKG | D7: 47 = N, 31 = R, 15 = D/S/M |
| P/N/R/D | 0x1D2 | DKG | D0: 240 = Car off, 225 = P, 210 = R, 180 = N 120 = D/S/M |
| D/S/M | 0x1D2 | DKG | D4: 240 = D, 241 = S, 242 = M |
I use 0x1D2 for the mode and 0x0BA for the gear position.
Last edited:
I contacted https://www.trsperformance.co.uk/ and they say they can cater for any gear ratio. They currently do 3.62 for the M3 DCT So it's possible they have cracked the TCU. I haven't gotten to the stage where I can test anything as I'm still buying parts.
Could someone who has everything ready please contact them and see if it is acts possible .
Could someone who has everything ready please contact them and see if it is acts possible .
Attachments
Added SportButton state. (That is at 0x1D2, byte 3, mask 4).
Though for making different FDRs work, the only thing that needs to be decoded is wheel speeds. Everything else can be copied raw from PT-CAN to Fake-PT-CAN.
Unless you have extra features in mind.
One, that I am thinking of is clutch-kick. According to MAXXECU, it seems that the software already has a way to open clutches, so it should be easy to implement.
I am thinking that perhaps the wheel speed intercepting solution could become a separate thread at some point. There surely will be more things to cover like safety, making sure the car goes ok to deep sleep, extra features
Added SportButton state. (That is at 0x1D2, byte 3, mask 4).
Though for making different FDRs work, the only thing that needs to be decoded is wheel speeds. Everything else can be copied raw from PT-CAN to Fake-PT-CAN.
Unless you have extra features in mind.
One, that I am thinking of is clutch-kick. According to MAXXECU, it seems that the software already has a way to open clutches, so it should be easy to implement.
I am thinking that perhaps the wheel speed intercepting solution could become a separate thread at some point. There surely will be more things to cover like safety, making sure the car goes ok to deep sleep, extra features
Awesome, I’ll check out 1D2 can’t believe I missed that. I’m working on a different, sort of related project right now, as a personal project that I’ll post about pretty soon.
For a GTS translator yeah, I’d just intercept GWS commands and convert to M3 commands as close as we could, use the sport button to cycle through drive logic modes, and then scale the wheel speed signals.
Other things could be added as needed/wanted... clutch kick would be awesome, that could definitely be done if we can figure out how to command it. If we could figure out a clutch kick I could likely implement adjustable launch control using torque demand commands and steering wheel buttons on the 135/335.
@Olza any idea on a clutch kick command?
Sleep and all that is very easy, currently I just use the WKUP hardware line to wake/sleep. Draws almost no power when sleeping. My main professional focus is battery powered embedded systems so this area is a walk in the park.
It would be opening/closing the clutch with a command. Like pressing/releasing the clutch pedal.
Regarding clutch kick - The M3 DSC document mentions “releasing the clutches mid corner to stabilise/keep the weight balance of the car”
don’t know how you’d go about finding out what that command looks like but it’s there
don’t know how you’d go about finding out what that command looks like but it’s there
We could trigger clutch kick on the rising edge of handbrake state
Since transmission torque capacity depends on one of the requests from ECU (-1023 to 1023Nm according to MAXXECU.) perhaps it would be enough to intercept the right CAN signal and basically do the same as maxxecu suggested, that is request negative torque until engine speed increases by certain RPMs. Who knows if it is that simple... Maybe torque reported back would also need to be faked.
The torque request is probably in one of these first three messages that come from ECU:
On the firmware side, I wonder how these guys succeded with the hacking https://www.e90post.com/forums/showpost.php?p=21388662&postcount=15.
Since transmission torque capacity depends on one of the requests from ECU (-1023 to 1023Nm according to MAXXECU.) perhaps it would be enough to intercept the right CAN signal and basically do the same as maxxecu suggested, that is request negative torque until engine speed increases by certain RPMs. Who knows if it is that simple... Maybe torque reported back would also need to be faked.
The torque request is probably in one of these first three messages that come from ECU:
| •0xA8 •0xA9 •0x1D0 •0xAA •0x2FA •0x2FC •0x308 •0x310 •0x34F •0x3EF •0x1E1 •0x130 •0x330 •0xBF •0xAC •0xB4 •0xB6 •0xCE •0xC4 •0x19E •0x2B2 •0x374 •0x1A3 •0x1B4 |
On the firmware side, I wonder how these guys succeded with the hacking https://www.e90post.com/forums/showpost.php?p=21388662&postcount=15.
We could trigger clutch kick on the rising edge of handbrake state
Since transmission torque capacity depends on one of the requests from ECU (-1023 to 1023Nm according to MAXXECU.) perhaps it would be enough to intercept the right CAN signal and basically do the same as maxxecu suggested, that is request negative torque until engine speed increases by certain RPMs. Who knows if it is that simple... Maybe torque reported back would also need to be faked.
The torque request is probably in one of these first three messages that come from ECU:
•0xA8
•0xA9
•0x1D0
•0xAA
•0x2FA
•0x2FC
•0x308
•0x310
•0x34F
•0x3EF
•0x1E1
•0x130
•0x330
•0xBF
•0xAC
•0xB4
•0xB6
•0xCE
•0xC4
•0x19E
•0x2B2
•0x374
•0x1A3
•0x1B4
Interesting idea, 0xA8 and 0xA9 both have engine output torque, I wonder if zeroing this out would trick the DCT into opening the clutches. 0x1D0 is engine temperature data.
I wish I had a manual car to log and see what the differences are. @Olza, any clue on where the DCT gets engine torque from? 0xA8 Bytes 3 and 4? 0xA9 Byte 5?
If I thought logically I would guess it would come from 0xA8, as there's nothing else, other than a brake pedal on/off type trace, in this packet, so a manual car wouldn't even need to transmit it. 0xA9 has throttle position and a couple other things I suspect are for the DSC
if you are talking about main MOTORISTMOMENT_WERT, then it used from 0xA8 (1-2 bytes offset).
also used
- torque1? from 0xA8 (2-3 bytes offset)
- torque2? from 0xA9 (2-3 bytes offset)
- torque3? from 0xA9 (3-4 bytes offset)
- torque4? from 0xA9 (4-5 bytes offset)
- torque5? from 0xA9 (5-6 bytes offset)
- torque6? from 0xA9 (6-7 bytes offset)
- Drehmoment from 0xAA (1-2 bytes offset)
anyone have that torque descriptions?
yes, two bit-quoters in byte at offset 5 (im counting from 0), use lowest one 4 bits:
1 - 6 = Drive Logic Mode 1-6 - example for mode 5 - xxxx0101
7 - 12 = Rennstart Mode 1-6
Similar threads
