Vida CEM swapping

[vtl]

And my experiments show that if I send different data, the problem is more likely to occur.

What do you mean by "different data"? Out of curiosity.

[dikidera]

And my experiments show that if I send different data, the problem is more likely to occur.

What do you mean by "different data"? Out of curiosity.

Well, if I spam the CAN bus with 0xFF bytes(bits set to 1) as the data with no sleeps(so as fast as possible), transmission is good and there are no retransmitted frames(although I'd have to give that SBL to rkam so he can confirm).

As soon as there is any other data, and zero bits seem to trigger it more, there are many more duplicates(retransmitted frames). And sleeping up to 1 millisecond per sent CAN frame, does little to fix this.

[rkam]

In theory it should take about 16.9 seconds to send 32768 can frames with 8-byte of data without any pause in between.
With 0.100ms pause in between, it should be around 20.2 seconds.
I'll have a look at the cable signal later this evening, to see if the pause is really there.

If the pause is not there, it means that the software or hardware thinks the CAN frame has been sent before all the bits are transmitted.
But with 1ms pause, it should not be an issue anyway.

Dataloss started to happen not too long after all the FFs was received. (First 0x8000 in external flash is filled with FF).

[dikidera]

Yes it is a peculiar situation, if I send only 8 0xFF bytes all the time, there are no problems, but as soon as the data is NOT 0xFF, there are transmission problems.

Certain data seems to consistently cause transmission errors. The order of the bits seems to play a role. I will demonstrate with some small logs.

[vtl]

Well, if I spam the CAN bus with 0xFF bytes(bits set to 1) as the data with no sleeps(so as fast as possible), transmission is good and there are no retransmitted frames(although I'd have to give that SBL to rkam so he can confirm).

As soon as there is any other data, and zero bits seem to trigger it more, there are many more duplicates(retransmitted frames). And sleeping up to 1 millisecond per sent CAN frame, does little to fix this.

How does your hardware setup look like? Photo, schematics?

[dikidera]

Well, if I spam the CAN bus with 0xFF bytes(bits set to 1) as the data with no sleeps(so as fast as possible), transmission is good and there are no retransmitted frames(although I'd have to give that SBL to rkam so he can confirm).

As soon as there is any other data, and zero bits seem to trigger it more, there are many more duplicates(retransmitted frames). And sleeping up to 1 millisecond per sent CAN frame, does little to fix this.

How does your hardware setup look like? Photo, schematics?

RPI4B with two CAN boards(only one is connected as the ECU is on the bench) with MCP2515 and TJA1050 wired to the ecu via female-female jumper cables. And 120ohm termination. With SPI bus clock forced constant.

But it doesn't explain why rkam is also experiencing the same thing with his Kvaser tool.

[vtl]

RPI4B with two CAN boards with MCP2515 and TJA1050 wired to the ecu via female-female jumper cables. And 120ohm termination. With SPI bus clock forced constant.

But it doesn't explain why rkam is also experiencing the same thing with his Kvaser tool.

Can you shoot a picture? Subtle nuances are important, like thin and twisted wires, good power, etc. I can't count how many people reported here that they've had problem with the cracker, only because of subpar hw implementation. Also termination is not needed when connecting to OBD port in car.

Sending non-uniform data results in less signal transitions, CAN controller only has to do bit stuffing. My jerk-knee reaction was you have signal integrity problem in your hw.

[dikidera]

This is it.

So the 2 can boards are connected via that white wire to the 5v, and I found it best to wire them like that so that they share those 5 volts.

I am using a computer power supply. I doubt the ECU is drawing that much power to cause vdroop.

[vtl]

Okay, a few things...

- computer power supplies are super noisy, you want to add a good filter or, better, use a lab power supply. My cracker literally stopped cracking one day when old PSU silently decided to go and made the power output noisy. Once replaced with a new/better PSU, it all cured
- always use a twisted pair for differential signal. They are twisted for reason. At least use a flat cable, so the + and - wires go side by side and pick up the same interference
- separate SI/SO physically from anything else, especially SCK, as they could pick up interference, and they are not differential
- make sure CAN transceiver get a lot of good power. It consumes a lot of power when it drives the signal at high speeds
- use as thin CAN wires as possible - that reduces wire capacity that CAN transceiver has to overcome

[Jackw16]

gonna work on the wiki later/tomorrow, would anyone be interested in my two branches im working on, one very simple uses flashed esp01 for wifi serial monitoring of progress and second uses an oled like modunlock but better and obvs would be a branch on github for anyone to use