Vida CEM swapping

[vtl]

I'm becoming suspected that early P2 does not crack because of the same issue that hits early P1. If we toss out the P1 issue, brick-shaped P2 CEMs may crack as well.

These CEMs are the slowest, I think - the oscillator I found nearby the chip is 4 MHz only.

Other observations:

- latency has very little deviation when the same byte sequence is sent over and over, i.e. there's no semi-random background activity in the CEM while it's in programming mode

- latency deviation is terrible when different bytes are sent. Feels almost like CPU does the CAN bit stuffing counting in sw, but I was not able to level that out by counting bits stuffed myself and adjusting latency results based on probable delay per bit stuffed

- latency accumulation is very visible when the right subsequence is sent. 1 or 2 bytes don't make a difference, but 3 and, especially, 4 totally triggers it. Of course, CALC_BYTES=4 would be very slow on a 250 Kbps, but it is still better to leave the car overnight plugged into battery charged than taking the CEM out, cutting the tin box and soldering a programmer to the PCB or blowing the flash chip off

[RickHaleParker]

- latency accumulation is very visible when the right subsequence is sent. 1 or 2 bytes don't make a difference, but 3 and, especially, 4 totally triggers it. Of course, CALC_BYTES=4 would be very slow on a 250 Kbps, but it is still better to leave the car overnight plugged into battery charged than taking the CEM out, cutting the tin box and soldering a programmer to the PCB or blowing the flash chip off

Perhaps a special crack routine for CEM-B. Use Heap's algorithm to step through the 4 byte permutations until you get a large jump in latency .... ?

Or perhaps use Use Heap's algorithm for the first 3 bytes then run through 4 sequentially. At 500 per second it would take at the most 33.33 minutes to get the first three.

[vtl]

Could it be so that the codes sees the reply, irq is not asserted timely, the code keeps counting the longest idle period between the end of the reply message and irq? If so, it is screwed. It is assumed to find the idle period between last bit of the request and first bit of the reply.

Writing to IO pin and capturing both CAN traffic and IO pin in logic analyzer would definitely show that.

Checked that hypothesis, the interrupt comes in about 35 us after the last (ACK) bit of the reply.

[sirloins]

Checked that hypothesis, the interrupt comes in about 35 us after the last (ACK) bit of the reply.

Interesting, sorry today I decided to get my K-line working so I could try this on my P2. (the keep alive worked great!)

If I disable the check for intr here:

Code: Select all

@@ -375,7 +373,7 @@ bool cemUnlock (uint8_t *pin, uint8_t *pinUsed, uint32_t *latency, bool verbose)
   canMsgSend (CAN_HS, 0xffffe, unlockMsg, verbose);
 
   start = end = TSC;
-  while (!intr && TSC < limit) {
+  while (TSC < limit) {
     /* if the line is high, the CAN bus is either idle or transmitting a bit */
 
     if (digitalRead(CAN_L_PIN))

but leave the canbus interrupts etc all enabled (normal). Then I get a lot more varied latency response, similar to when I disable interrupts, but it is still unable to find the right bytes, so that makes me believe that the interrupt routine in FlexCan is taking a long time, or is triggered quite often while receiving a message. That is where I will try to be logging some more info.

On the other hand, if removing the fifo/can interrupts works, I could provide a simple patch to the code. Or at least have it as a branch people could try on their P1s.

I wonder if this change could make cracking the PIN on P2s faster as well? I found with the interrupts disabled the latency difference was very obvious when you hit a correct byte. Only one pass was needed in my limited testing.

[RickHaleParker]

Which Teensy pins are K-line TX and RX assigned to ?

[vtl]

Which Teensy pins are K-line TX and RX assigned to ?

Serial3, TX only (I left RX unconnected).

[vtl]

If I disable the check for intr here:

but leave the canbus interrupts etc all enabled (normal). Then I get a lot more varied latency response, similar to when I disable interrupts, but it is still unable to find the right bytes, so that makes me believe that the interrupt routine in FlexCan is taking a long time, or is triggered quite often while receiving a message. That is where I will try to be logging some more info.

On the other hand, if removing the fifo/can interrupts works, I could provide a simple patch to the code. Or at least have it as a branch people could try on their P1s.

I wonder if this change could make cracking the PIN on P2s faster as well? I found with the interrupts disabled the latency difference was very obvious when you hit a correct byte. Only one pass was needed in my limited testing.

I've tried no FIFO/IRQ on brick-shaped CEM, still a miss, and no visible difference.

This is with interrupts, but the code measures exactly what it should measure.

Untitled.png (134.74 KiB) Viewed 678 times

Code: Select all

@@ -368,18 +369,28 @@ bool cemUnlock (uint8_t *pin, uint8_t *pinUsed, uint32_t *latency, bool verbose)
 
   /* maximum time to collect our samples */
 
-  limit = TSC + 2 * 1000 * clockCyclesPerMicrosecond();
+  limit = TSC + 4 * 1000 * clockCyclesPerMicrosecond();
   intr = false;
 
   /* send the unlock request */
   canMsgSend (CAN_HS, 0xffffe, unlockMsg, verbose);
 
+  static bool pin3 = false;
+  static bool pin4 = false;
+
+  pin3 = !pin3;
+  digitalWrite(3, pin3);
+  pin4 = !pin4;
+  digitalWrite(4, pin4);
+
   start = end = TSC;
   while (!intr && TSC < limit) {
+//  while (TSC < limit) {
     /* if the line is high, the CAN bus is either idle or transmitting a bit */
 
-    if (digitalRead(CAN_L_PIN))
+    if (digitalRead(CAN_L_PIN)) {
       continue;
+    }
 
     /* the CAN bus isn't idle, it's the start of the next bit */
 
@@ -387,11 +398,18 @@ bool cemUnlock (uint8_t *pin, uint8_t *pinUsed, uint32_t *latency, bool verbose)
 
     /* we only need to track the longest time we've seen */
 
-    if (end - start > maxTime)
+    if (end - start > maxTime) {
       maxTime = end - start;
+
+      pin4 = !pin4;
+      digitalWrite(4, pin4);
+
     /* start of the next sample */
 
+    }
     start = end;
+    pin3 = !pin3;
+    digitalWrite(3, pin3);
   }
 
   /* default reply is set to indicate a failure */
@@ -1002,6 +1020,8 @@ void setup (void)
   /* set up the pin for sampling the CAN bus */
 
   pinMode (CAN_L_PIN, INPUT_PULLUP);
+  pinMode (3, OUTPUT);
+  pinMode (4, OUTPUT);
 
 //  set_arm_clock (180000000);
 

[RickHaleParker]

Serial3, TX only (I left RX unconnected).

Pin #14 Serial TX3

Trying to plan ahead so we can turn the hardware into a full fledged J2534 with PIN cracking sometime in the future.

Pin #14 Serial TX3 K-Line
Pin #15 Serial RX3 K-Line

Then I will probably need one of the digital pins for switching the K-Line from slave to master mode. Still need to figure out how I going to accomplish that.

[alevol]

What if use Teensy digital pin interrupt instead of FIFO interrupt on Pin2? Can bus FIFO interrupt might be slower, since it is likely to be software generated.
Just asking

[vtl]

What if use Teensy digital pin interrupt instead of FIFO interrupt on Pin2? Can bus FIFO interrupt might be slower, since it is likely to be software generated.
Just asking

Interrupt per se does not participate in the latency counting code, it only signals when the reply has been fully received. It looks like something unusual happens in P1 case, and I hope sirloins or someone else with the logic analyzer would be able to capture both CAN-bus and debugging IO pins as outlined here: viewtopic.php?p=594757#p594757