Vida CEM swapping

[sirloins]

I didn't think I was spoiling the precision.. Instead of "1 latency == 1us" now "1 latency == 0.25us" ... So there is more precision?

I admit the naming in the patch/code is not great, I didn't know what to call it.

[vtl]

I didn't think I was spoiling the precision.. Instead of "1 latency == 1us" now "1 latency == 0.25us" ... So there is more precision?

In your patch - yes. In my patch I just collect the total CPU cycles, so the precision is even greater than in your patch. This is what makes me a bit nervous: cracks with precision improved only slightly, does not with a full possible precision.

May I ask you to collect the 720 logs w/ your patch and my patch, with DUMP_BUCKETS defined?

Cheapest 8690720 is $150 on ebay

[sirloins]

Okay, sorry, yes I see what you are saying.

I am assuming the weighted product being used makes the difference, but let me get the logs and we can see for ourselves what is going on exactly.

[vtl]

Thinking about precision.

MCU runs at 8 MHz, each clock cycle is 0.125 us. It looks like egress CAN frame starts at arbitrary time, aligned to MCU clock rate, not CAN clock rate. In this case the other side (Teensy) will see a clock-accurate latency.

Of course, every signal has some noise. By switching the histogram resolution from 1 us to 0.25 us you make it functioning like a primitive filter that recovers a real clock cycles. In that case, using 0.125 us buckets would make it even better?

[sirloins]

Attached are two logs from the first round of the first byte and part of the second round.

The correct byte is 13 for the first position.

I can run them longer or to completion as well, let me know if you think that would be useful.

[RickHaleParker]

Didn't work... Interesting. And yet rounding the result up to a quarter of microsecond, or, in other words spoiling the precision in a terrible way, makes it work?

Spoils the precision or the accuracy?
Accuracy is how close the measured value is to the true value.
Precision is the smallest unit of measurement. ( how many decimal places ).

[sirloins]

Thinking about precision.

MCU runs at 8 MHz, each clock cycle is 0.125 us. It looks like egress CAN frame starts at arbitrary time, aligned to MCU clock rate, not CAN clock rate. In this case the other side (Teensy) will see a clock-accurate latency.

Of course, every signal has some noise. By switching the histogram resolution from 1 us to 0.25 us you make it functioning like a primitive filter that recovers a real clock cycles. In that case, using 0.125 us buckets would make it even better?

Good points, let me try with 0.125us and the dump_buckets set. I will update the logs.

[sirloins]

Ok, first of all, thanks for questioning why my change works... turns out I don't even know why it works lol. Lets get to the bottom of it.

When attempting to do the 0.125us change (ie set my LATENCY_RESOLUTION to 8 ) I found a bug in the change I submitted.

Specifically here (my change):

Code: Select all

/* maximum time to collect our samples */
limit = TSC + 2 * 1000 * clockCyclesPerLatencyUnit();

Recall this function returns clockCyclesPerMicrosecond / LATENCY_RESOLUTION... So by setting the LATENCY_RESOLUTION to 4 I was limiting the maximum time that we would wait for a sample.

Instead of the timeout being 2ms, it was now 0.5ms.

I should have left this alone since it is just a timeout.

So I fixed this, and set it back to:

Code: Select all

/* maximum time to collect our samples */
limit = TSC + 2 * 1000 * clockCyclesPerMicrosecond();

Interesting, now everything doesn't work again, even with the histogram in 0.25us.

So I tried your patch again vtl, this time with the following:

Code: Select all

/* maximum time to collect our samples */
limit = TSC + 2 * 1000 * clockCyclesPerMicrosecond()/4;

It works now. *edit: I also checked with this single change from the master branch and it also works

So this means the only thing making this work was limiting the timeout (limit) in the cem_unlock function. Now, obviously, we don't need the change I submitted, and I can log a bit more so we can create a more effective algorithm.

[sirloins]

Attached are four log files.

p1_master_div4.txt - Master branch with: limit = TSC + 2 * 1000 * clockCyclesPerMicrosecond()/4;

p1_master_div4_full.txt - full log to completion of the above file.

p1_31254749_div4_full.txt - full log on my 31254749 (in car)

p2_master_nodiv.txt - Master branch, no changes.

[Sh4rp]

With the code change sirloins proposed I was able to crack my 8690720 CEM.