Vida CEM swapping

[repair]

For fun, I put together a circuit with a display. The finished board with Teensy and MAX3051 drivers was assembled four years ago.
There is a CEM L with the number 30728542 (it is in the sketch list). So, Teensy, with different sketches, either does not find a single byte correctly or finds only the first two bytes to be correct. We tested options with USB power and external power via a 7805 converter.
In addition, Smok UHDS on the same CEM finds all bytes correctly in 7-10 minutes.
What is the problem with the Teensy circuit in this case?

[vtl]

For fun, I put together a circuit with a display. The finished board with Teensy and MAX3051 drivers was assembled four years ago.
There is a CEM L with the number 30728542 (it is in the sketch list). So, Teensy, with different sketches, either does not find a single byte correctly or finds only the first two bytes to be correct. We tested options with USB power and external power via a 7805 converter.
In addition, Smok UHDS on the same CEM finds all bytes correctly in 7-10 minutes.
What is the problem with the Teensy circuit in this case?

30728542 is a "difficult" one. I have it, the third byte success is always on the edge. My semi-guessed explanation why some CEMs are difficult: viewtopic.php?p=602113#p602113 Have seen 3 different routine alignments in memory, that one is the most difficult.

How Smok cracks it? P3-style, via hash collision?

[vtl]

Teensy and MAX3051 drivers

The cracker has to deal with a lot of clock domain transitions. Each transition adds jitter and steals the precision. Some transceivers are worse than others. I never played with MAX3051, but it could be it adds more jitter than SN65HVD230DR does. You can try connecting Teensy's pin 2 to L pin of high speed CAN bus directly, that would avoid dealing with the transceiver.

Clock (frequency) domain problem explanation: viewtopic.php?p=659200#p659200

Assuming your hw was assembled right. This P/N is what I've used the most during cracker development. First two bytes are 100% reliable for me.

[repair]

How Smok cracks it? P3-style, via hash collision?

I don't know how he does it. But Smok, after several attempts on this CEM, always identifies all bytes correctly and quickly. Although there were two different CEMs on which he only found two bytes correctly.

[repair]

You can try connecting Teensy's pin 2 to L pin of high speed CAN bus directly, that would avoid dealing with the transceiver.

[vtl]

You can try connecting Teensy's pin 2 to L pin of high speed CAN bus directly, that would avoid dealing with the transceiver.

It didn't go into programming mode? Both CAN-buses are wired properly?

[Arty]

You can try connecting Teensy's pin 2 to L pin of high speed CAN bus directly, that would avoid dealing with the transceiver.

I had a similar problem. It turned out that one of the CAN transceivers was most likely faulty. I replaced both and everything worked. My CEM L has the same part number.

[vtl]

I had a similar problem. It turned out that one of the CAN transceivers was most likely faulty. I replaced both and everything worked. My CEM L has the same part number.

I lot of counterfeit Chinese junk these days. A few stories right in this thread that people got it working by replacing the transceivers with the same ones, but from a different seller.

[dikidera]

After analysis from Claude on the vida sources, it appears that when enumerating ECUs , the communication layer for each ECU is stored in Scripts, and not in the T_Init tables which are fetched via vadis_GetHwInit or vadis_GetDiagTimings SQL stored procedures. Those return incorrect speeds for our profiles, so Scripts instead supersede these tables, scripts describe how to read and clear DTCs, how to enter DownloadMode etc.

[Arty]

Yes. And this: viewtopic.php?p=575090#p575090

Get both versions of m16c-flasher.de, beta can read, release can write Add next to the config file:

[Controller]
Name=M32C@0xFC0000
Group=Generic
BaseAdr=FC0000
Blocks=1
From=FC0000
Size=40000
[end]

And select this controller in the menu.

If I understand correctly, then using this method I can get the flash from my CEM-L, modify it and write it back, right?