Vida CEM swapping

[vtl]

It does slow down the process a bit (no more intr to break the while loop), but reliably found the first byte after the first pass. I think the only item triggering interrupts would be the two can controllers?

Yes. But why the CAN-LS side would be sending anything? It should be quiet in programming mode. Maybe try to unplug CAN-LS from cracker after going into programming mode?

[sirloins]

I do not have CAN_LS connected to this CEM on my bench, so I don't think it is that. I also logged messages in the can interrupt routine that set intr = 1. All messages were just responses to the unlock routine...

I also disable the LS can init, no change.

Update: Deleted the diff I attached.. need to make sure I am not crazy first.

[vtl]

Update: Deleted the diff I attached.. need to make sure I am not crazy first.

It sounds like you have too much fun alone with your 720. I think, two more beers and I'll convince myself I need that 720 CEM on ebay =)

[sirloins]

I'm not really convinced there is a difference between the 719 I have and the 720, but I can do more comparisons.

I can mail you one of my 719 or the 720. The 720 is just the single CPU board now, I removed the fuse/relay boards.

This patch also works, so my thought is that the FlexCAN_T4 interrupt routines are causing issues with the accurate measurement of latency. This patch simply disables the FlexCAN_T4 interrupts/FIFO. (also is just hardcoded to can_hs bus for receiving right now)

Code: Select all

diff --git a/volvo-cem-cracker.ino b/volvo-cem-cracker.ino
index d0e9129..900f20e 100644
--- a/volvo-cem-cracker.ino
+++ b/volvo-cem-cracker.ino

@@ -214,7 +214,7 @@ bool canMsgReceive (can_bus_id_t bus, uint32_t *id, uint8_t *data, int wait, boo
 
     /* check if a message was available and process it */
 
-    if (msg_avail) {
+    if (can_hs.read(msg)) {
 
       /* process the global buffer set by can_hs.events */
 
@@ -375,7 +375,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))

@@ -933,11 +933,12 @@ void can_ls_init(int baud)
 void can_hs_init(int baud)
 {
   can_hs.begin();
+  //can_hs.setClock(CLK_80MHz);
   can_hs.setBaudRate(baud);
-  can_hs.enableFIFO();
-  can_hs.enableFIFOInterrupt();
-  can_hs.setFIFOFilter(ACCEPT_ALL);
-  can_hs.onReceive(can_hs_event);
+  //can_hs.enableFIFO();
+  //can_hs.enableFIFOInterrupt();
+  //can_hs.setFIFOFilter(ACCEPT_ALL);
+  //can_hs.onReceive(can_hs_event);
   printf ("CAN high-speed init done.\n");
 }

So disabling all interrupts makes the code work on P1 CEMs.
Disabling just the FlexCAN interrupts makes it work.
Causing the loop to exit out before the can interrupt is triggered also works.

I think the next step is to do what you mentioned vtl, get some traces of what is going on with the actual CAN_L line and stuff around this time.

[RickHaleParker]

Can you try rerouting pin 2 to CAN differential L lane? From dashed to red.

In a perfect system that can work. However, if there is a fault in the CAN bus such as a short to 12v it will take out the detect pin in the Teensy possibly the whole Teensy. Can transceivers are fault tolerant to typically 60V.

If the detector needs to listen on the CAN differential without interference from TX, a third CAN Transceiver setup as a CAN Sniffer ( listen only ) might be the answer.

[vtl]

So disabling all interrupts makes the code work on P1 CEMs.
Disabling just the FlexCAN interrupts makes it work.
Causing the loop to exit out before the can interrupt is triggered also works.

Interesting.

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.

[blasaab]

I'm not really convinced there is a difference between the 719 I have and the 720, but I can do more comparisons.

I can mail you one of my 719 or the 720. The 720 is just the single CPU board now, I removed the fuse/relay boards.

This patch also works, so my thought is that the FlexCAN_T4 interrupt routines are causing issues with the accurate measurement of latency. This patch simply disables the FlexCAN_T4 interrupts/FIFO. (also is just hardcoded to can_hs bus for receiving right now)

Code: Select all

diff --git a/volvo-cem-cracker.ino b/volvo-cem-cracker.ino
index d0e9129..900f20e 100644
--- a/volvo-cem-cracker.ino
+++ b/volvo-cem-cracker.ino

@@ -214,7 +214,7 @@ bool canMsgReceive (can_bus_id_t bus, uint32_t *id, uint8_t *data, int wait, boo
 
     /* check if a message was available and process it */
 
-    if (msg_avail) {
+    if (can_hs.read(msg)) {
 
       /* process the global buffer set by can_hs.events */
 
@@ -375,7 +375,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))

@@ -933,11 +933,12 @@ void can_ls_init(int baud)
 void can_hs_init(int baud)
 {
   can_hs.begin();
+  //can_hs.setClock(CLK_80MHz);
   can_hs.setBaudRate(baud);
-  can_hs.enableFIFO();
-  can_hs.enableFIFOInterrupt();
-  can_hs.setFIFOFilter(ACCEPT_ALL);
-  can_hs.onReceive(can_hs_event);
+  //can_hs.enableFIFO();
+  //can_hs.enableFIFOInterrupt();
+  //can_hs.setFIFOFilter(ACCEPT_ALL);
+  //can_hs.onReceive(can_hs_event);
   printf ("CAN high-speed init done.\n");
 }

So disabling all interrupts makes the code work on P1 CEMs.
Disabling just the FlexCAN interrupts makes it work.
Causing the loop to exit out before the can interrupt is triggered also works.

I think the next step is to do what you mentioned vtl, get some traces of what is going on with the actual CAN_L line and stuff around this time.

Hi where are u placing this patch in the cracker?

[sirloins]

I did wire up a TJA1020 to try this in my 2004 CEM-B. Part number is 30657629.

If anyone has a flash dump for this model I would like to take a look. Thanks!

blasaab, regarding the patch above, it contains the lines that were removed (- sign) and ones that I replaced them with (+ sign).

[vtl]

If anyone has a flash dump for this model I would like to take a look. Thanks!

Brick CEM analysis: viewtopic.php?p=582635#p582635 The dump sent to your email found in git commit.

[sirloins]

Brick CEM analysis: viewtopic.php?p=582635#p582635 The dump sent to your email found in git commit.

Thank you!