Vida CEM swapping

[ghettob]

hi.

I've encountered a massive obstacle with the teensy build.

I've managed to get the car to programming mode, but the teensy keeps bootlooping causing the car to go in and out of programming mode thus being unable to crack the pin.

Any advice?

Copy your terminal output, paste on gist.github.com, share a link here.

[ghettob]

I reuploaded the p3 ino to the teensy and plugged the module to the car. Serial monitor shows this.


I then checked the upload output, which had red lines.

[vtl]

It is making progress, look for "hash collision"

[dikidera]

The ETM was the module that helped me crack CAN signal configuration, understanding how the CAN ids were calculated in the entire P2 Volvo lineup. Really good learning experience.

Would you mind sharing some of your insights?
Damien Maguire (known for converting BMWs and lately also Volvos to Electric Vehicles) and myself have been working on reverse engineering the CAN messages on the P2 series, but since we have different generations of cars (he has 2003, I have 2002), it's twice the amount of work without knowing the system behind it.
Edit: Here is the repository with the start of DBC files and some annotated logs: https://github.com/damienmaguire/Volvo- ... ngineering

From what I found out is that the P2 generation used the "Volcano" software to generate the CAN bus IDs and timing. There seems to be some structure in the IDs but I could never really pinpoint it. There always was "oh, this looks like it could be it" and then there's an outlier that broke the structure...

It is actually quite simple. It is the physical representation of the CAN module's memory layout.In other words, the ID is the serialized data in the registers of whatever MCU.Sometimes depending on the MCU, the ID is encoded with/without the RTR/IDE bit.

There is no one solution to decode them all, each MCU has a different CAN layout, so encoding of IDs will be different everywhere.

Here is a python script, that given a HW part number, will extract all diagnostic parameters with names and units(if applicable) from VIDA. It was written by AI yes. May contain bugs.

In the meantime I have started reverse engineering TF80SC. It has been most illuminating, we can see a different architecture compared to AW55 mediated by an improved compiler, data is now passed in structures, pointers, pointers to pointers.

We have several important structures, 4 identical structures related to commands, and 4 identical structures for what is likely shift process.

[radziuC30]

hi.

I've encountered a massive obstacle with the teensy build.

I've managed to get the car to programming mode, but the teensy keeps bootlooping causing the car to go in and out of programming mode thus being unable to crack the pin.

Any advice?

Copy your terminal output, paste on gist.github.com, share a link here.

Hello, I have the same problem, how can I solve it?

[ghettob]

It seems that it is not getting throught to start the process correctly, as it keeps waking the car from programming mode and putting it back in.

I had the cracker in the v60 for over 2 hours and it just kept looping in and out of programming mode.

[vtl]

Grab everything you see on the teensy's console, end to end, paste to gist.github.com, drop a link here.

[crasbe]

Here is a python script, that given a HW part number, will extract all diagnostic parameters with names and units(if applicable) from VIDA. It was written by AI yes. May contain bugs.

Thank you for the script! I played around with SQL requests and some Python parsing too, but your script is a lot nicer indeed.
My VIDA installation is stuck in an old 32-bit Windows 7 VM, so I'll probably have to get a newer Windows version to export the database to SQLite format and actually play around with the script.

What is still unclear to me: as far as I could tell the VIDA database only contains the diagnostic responses? At least the links that vtl posted were all based on diagnostic requests. What I'm interested in is the normal CAN bus communication, which does not include the diagnostic requests.
The goal would be to replace the ECM entirely and "pretend" to be the ECM, which would require replicating all the CAN messages it usually sends. Those aren't the diagnostic messages though.

Is that what the "status" category is for? Is that the data that's sent on the CAN buses during normal operation? (As I said, I haven't played around with your script yet, maybe the answer would be obvious from the output).

[ghettob]

Grab everything you see on the teensy's console, end to end, paste to gist.github.com, drop a link here.

I have the pin already for this car and it's not even close. Terminal output is from a 15min session

Master branch does not even start the programming mode, so all the gists are from p3 branch

[vtl]

Grab everything you see on the teensy's console, end to end, paste to gist.github.com, drop a link here.

I have the pin already for this car and it's not even close. Terminal output is from a 15min session

Master branch does not even start the programming mode, so all the gists are from p3 branch

It is making progress. P3 CEM falls off the programming mode when punched hard, that's why it awakes and gets down again. The only way it stays in programming mode is if message rate is greatly reduced, to about what DiCE can do.

p3 code is not integrated into master, yes. I was thinking of integrating sirloin's one_pass and p3 branches (and now cem_b, too), but testing the code on at least 4 CEMs would kill me.