Vida CEM swapping

[vtl]

I am interpreting that as SardineCAN includes the translations. How else could Olaf be sure it would work with "various diagnostic programs". The whole idea of J2534 is that the client side developer does not need to know the low level protocols.

No, exactly in opposite: with higher-level protocol like OBD you don't need to know what car is it, every message and ECU ID is standard. In pass-through mode you need to know what car is it, down to every software version in every block. And talk in that specific protocol.

For example, when I've had DEM software updated in my XC70, my "mini-DiCE" lost knowledge of how to talk to DEM, because the internal format has changed. Or maybe it was CCM, I don't remember.

VIDA knows everything: every combination is modules topology, and their sw versions, and IDs, and what variable is accessible at which address - all is programmed in VIDA's SQL database.

When VIDA can't deduce car's full topology from its VIN - it can't work with that car.

In OBD world you write your software once and it would work with future cars that weren't even thought of yet.

[RickHaleParker]

No, exactly in opposite: with higher-level protocol like OBD you don't need to know what car is it, every message and ECU ID is standard. In pass-through mode you need to know what car is it, down to every software version in every block. And talk in that specific protocol.

What am I misinterpreting in the following?

( source )
"J2534 is a concept that enables flash programming of an emission related ECU regardless of the communication protocol that is used by the ECU. The purpose is that only one tool (hardware device), often referred to as the pass-thru device, should be needed for all kind of ECUs. The connection between the J2534 device and the ECU is a SAE J1962 connector. The J2534 hardware device is to be connected to a standard PC which holds the Application Program Interface (API) from the vehicle manufacturer (Figure 1). The connection between the PC and the J2534 hardware device is up to the manufacturer of the tool, but USB is probably the most common. A J2534 API DLL is provided from the hardware tool developer which handles the communication to the PC. The J2534 document withholds requirements for the hardware and software of a J2534 tool. The communication protocols supported are; ISO9141, ISO14230 (KWP2000), J1850, CAN (ISO11898), ISO15765 and SAE J2610. In 2005 J1939 was also included.

The J2534 hardware works like a gateway between the vehicle ECU and the PC. This pass-thru device translates messages sent from the PC into messages of the protocol being used in the vehicle ECU.

"

[vtl]

Yeah, this article is written for idiots, so only idiot can understand it. Very vague and abstract.

Look in the available J2534 sources - they all send and receive raw, car/lower level protocol specific messages. It is duty of software to know what these bytes mean.

The interface between the software and scanner is standardized, though. For example, VIDA works fine with xHorse (only one CAN bus is available in hw though).

[RickHaleParker]

Yeah, this article is written for idiots, so only idiot can understand it. Very vague and abstract.

I always said dumbing down so that anybody can understand it is futile. Because there is nothing left to understand.

Look in the available J2534 sources - they all send and receive raw, car/lower level protocol specific messages. It is duty of software to know what these bytes mean.

J2534 is not translating the messages. It is routing the message to the correct ECU communication protocol ?
Analogous to a telephone switch board.

The interface between the software and scanner is standardized, though. For example, VIDA works fine with xHorse (only one CAN bus is available in hw though).

The full J2534 standard maybe standardized but I am seeing indications that the lower cost J2534 hardware manufactures are cutting cost by not including all the low level protocols. That is why a cheap J2534 interfaces works with specific vehicle manufactures rather the all vehicle manufactures.

[urosm]

I tried 3 times, but cracker won't or can't crack it.

You have IO Terminal or access to IO Terminal. Can you extract the .bin and/or PIN?

I have IO Terminal and can read flash .bin, but I need a PIN first.
And if I have a flash read on the bench (for example) I can extract PIN from it.

[RickHaleParker]

I have IO Terminal and can read flash .bin, but I need a PIN first.
And if I have a flash read on the bench (for example) I can extract PIN from it.

As VTL said there is something really off. Download the latest Teensy code and run it as is.
Double check all the connections on your Teensy.

Post some pictures of your Teensy build. Sometimes we can spot problems with the hardware build.

[urosm]

I posted pictures of my Teensy build earlier here on the forum.
The connections in the Teensy should be fine, as I read several P2 models without any problems.

I'll try again on the same car, with a new code.

Thanks!

[mariom598]

Question, did someone manage to change the car's configuration in the CEM module(P3 platform)?Thank you!

[ricked]

I tried 3 times, but cracker won't or can't crack it.

You have IO Terminal or access to IO Terminal. Can you extract the .bin and/or PIN?

I have IO Terminal and can read flash .bin, but I need a PIN first.
And if I have a flash read on the bench (for example) I can extract PIN from it.

trust me, reading flash first to get the pin is much faster, if i use the pin cracker the first 20 minutes goes fast then the script slows down to 70 plus minutes and does not find the pin, this is done on a win 10 64x, 8 core 64gb pc

[Canadian Moose]

Tried to crack the pin twice today unsuccessfully on 2007 XC70. CEM p/n: 30786890. Got the first 2 digits the same both times 79, 92 but on third digit got 2 different numbers. Will give it another go tomorrow.