Vida CEM swapping

[oscilloscope]

It was time to test out my frankenstein setup. I went to my S60, I plugged in my OBD cable and could see the CAN bus working fine, but then I sent one command to the car, 0xFF86000000000000, and the car restarts...any ideas why this happens?

what does that equate too that command code?

It depends. I use socketCAN and a can utility called cansend and do 000FFFFE#FF86000000000000 and the linux socket can driver takes care of communication via MCP2515

Ah you mean what the command does? It tells all the controllers(ECU,TCM,AEM whatever) to stop sending can commands and enter programming mode.

Right sounds cool,

although I do believe that on one part of this thread ,there was a mention about programming mode can only be entered at a certain point in the starting routine it's super early. , I'm definitely messing up the exsplaintion there, but that may be the reason it keeps restarting??

[vtl]

Ah you mean what the command does? It tells all the controllers(ECU,TCM,AEM whatever) to stop sending can commands and enter programming mode.

Do you send it to both CAN buses?

[dikidera]

Ah you mean what the command does? It tells all the controllers(ECU,TCM,AEM whatever) to stop sending can commands and enter programming mode.

Do you send it to both CAN buses?

No, as I was not aware there was an entirely different bus. The original obd pinout says pin 6 and 14 for normal CAN, but apparently pin 3 on Volvo is for the low speed CAN bus(although CAN is a differential protocol so there must be another pin, right?).
This will be a challenge. I have one CAN bus transceiver and due to the nature of SocketCAN, modifying the bitrate means disabling the interface, changing the bitrate and re-enabling, this process is slow and cannot happen simultaneously as I send the FF86 command on normal CAN.

[vtl]

No, as I was not aware there was an entirely different bus. The original obd pinout says pin 6 and 14 for normal CAN, but apparently pin 3 on Volvo is for the low speed CAN bus(although CAN is a differential protocol so there must be another pin, right?).
This will be a challenge. I have one CAN bus transceiver and due to the nature of SocketCAN, modifying the bitrate means disabling the interface, changing the bitrate and re-enabling, this process is slow and cannot happen simultaneously as I send the FF86 command on normal CAN.

It has another CAN bus (another pair of pins). Send your message to both. Baud rate is 125 or 250k, depending on model/model year.

[dikidera]

Yup, as you see in that circuit there, I need at least a second can bus controller. I wonder if I can macguyver this with just another MCP2515 tied to...the same TJA1050 I have right now.

Looking at the circuit above, I see a CAN controller, I don't see the actual tja1050 equivalent to handle differential signaling. Is all of that emulated on the teensy?

[rkam]

Teensy 4.0 and 4.1 has 3 built-in CAN controllers. You only need tranceivers on the outside.

It would be nice if we could make the Teensy into a J2534 device.

[dikidera]

So that is the secret to the teensy. Well, anyone can do it. You already have Sardine, so the boilerplate is there, somewhat. If I could do it with the RPI, it should be possible with the Teensy.

[vtl]

So that is the secret to the teensy. Well, anyone can do it. You already have Sardine, so the boilerplate is there, somewhat. If I could do it with the RPI, it should be possible with the Teensy.

The hw part of Sardine is done using Arduino. Porting the car-related code to another Arduino arch is usually a matter of switching to another CAN and timer library. I personally did it a few times for Volvo DDD project (https://github.com/vtl/volvo-ddd/tree/teensy/hw): Arduino DUE (built-in CAN) to ESP32 (MCP2515) to Teensy (built-in CAN). Because of the CAN and timers nature, it is not difficult to convert from one API to another, or even come up with a higher-level API that will be compatible with different implementations.

[dikidera]

Yup the only problem if I could call it that with RPI, is when you need to use Windows. Traditionally you need DICE unit with VIDA on Windows.
In my setup I need Windows laptop with which to SSH into the RPI + VIDA and then also RPI and it's periphperal CAN hardware. Arduino and teensy I am sure have drivers for direct interfacing with Windows and are physically much more compact.

[mikeak2001]

Hi everyone,

Just want to check in again, due to my businesss keeping me super busy I haven't really had a chance to update what I'm up too or doing. So here is a sneak peak.

Found another open project running on Github.
I've started meshing the two projects together. So we'll have a can logger/sniffer, we'll be able to send commands, crack pins etc through one piece of software. I currently monitor and test it on various models, ford, vauxhall, merc etc while im at work. Hopefully over christmas I'll have time to sit and continue with my little project.

I'm not the best at coding (just don't have the time to sit and practice), howevere i've always messed with python and c++ and it's all slowly coming back to me.

After some modified code this is a screenshot of the cansniff 2020 connected to the teensy with different code because it was built for early arduino. (bad picture i know because its taken from a video i took)


During my testing with my Autel that i use for programming keys/getting security pins etc I just use an obd Y splitter and record all the Canbus commands being sent/received.



Anyway, thats where I'm at right now.
Once the basic setup is there, I want to start making add ons for the software itself. So we can add functionality. (Just a thought for now)