FlexCAN_T4 - FlexCAN for Teensy 4

Could you please also share your receiving node's code, so I can start from your known-good setup and work backwards?
 
Receiver:
Code:
#include <FlexCAN_T4.h>
FlexCAN_T4<CAN3, RX_SIZE_256, TX_SIZE_64> Can0;

void setup(void) {
  Serial.begin(115200); delay(400);
  pinMode(6, OUTPUT); digitalWrite(6, LOW); /* optional tranceiver enable pin */
  Can0.begin();
  Can0.setBaudRate(500000);
  Can0.setMaxMB(16);
  Can0.enableFIFO();
  Can0.enableFIFOInterrupt();
  Can0.onReceive(canSniff);
  Can0.mailboxStatus();
  Can0.enableMBInterrupts();
  pinMode(13, OUTPUT);
}

void canSniff(const CAN_message_t &msg) {
  Serial.print("MB "); Serial.print(msg.mb);
  Serial.print("  OVERRUN: "); Serial.print(msg.flags.overrun);
  Serial.print("  LEN: "); Serial.print(msg.len);
  Serial.print(" EXT: "); Serial.print(msg.flags.extended);
  Serial.print(" RTR: "); Serial.print(msg.flags.remote);
  Serial.print(" TS: "); Serial.print(msg.timestamp);
  Serial.print(" ID: "); Serial.print(msg.id, HEX);
  Serial.print(" Buffer: ");
  for ( uint8_t i = 0; i < msg.len; i++ ) {
    Serial.print(msg.buf[i], HEX); Serial.print(" ");
  } Serial.println();
  static uint32_t _time = millis();
  Serial.print("Time between frames: ");
  Serial.println(millis() - _time);
  _time = millis();
}


void loop() {
}

Sender:
Code:
#include <FlexCAN_T4.h>
#include <elapsedMillis.h>

FlexCAN_T4<CAN3, RX_SIZE_256, TX_SIZE_128> LCAN;
elapsedMillis tsk1000msCounter;
CAN_message_t msg0E0;

void setup() {
  LCAN.begin();
  LCAN.setClock(CLK_60MHz);
  LCAN.setBaudRate(500000);
  LCAN.setMaxMB(10);
  LCAN.setMB(MB0, RX);   /* Set Mailbox RX Direction */
  LCAN.setMB(MB1, RX);   /* Set Mailbox RX Direction */
  LCAN.setMB(MB2, RX);   /* Set Mailbox RX Direction */
  for (int i = 4; i < 10; i++) LCAN.setMB((FLEXCAN_MAILBOX)(i), TX); /* Set Mailbox TX Direction */

  msg0E0.id = 0x0E0;
  msg0E0.len = 5;     // Data length

  Serial.begin(500000); delay(1000);
  LCAN.onReceive(canSniff);
  LCAN.enableMBInterrupts();
  Serial.print("LCAN Setup: ");
  LCAN.mailboxStatus();
}

void loop() {
  if (tsk1000msCounter >= 1000) {
    tsk1000msCounter = 0;  // Reset 1000ms timer
    msg0E0.buf[0]++;
    LCAN.write(msg0E0);
  }
}

void canSniff(const CAN_message_t &msg) {
  Serial.print("MB "); Serial.print(msg.mb);
  Serial.print("  OVERRUN: "); Serial.print(msg.flags.overrun);
  Serial.print("  LEN: "); Serial.print(msg.len);
  Serial.print(" EXT: "); Serial.print(msg.flags.extended);
  Serial.print(" RTR: "); Serial.print(msg.flags.remote);
  Serial.print(" TS: "); Serial.print(msg.timestamp);
  Serial.print(" ID: "); Serial.print(msg.id, HEX);
  Serial.print(" Buffer: ");
  for ( uint8_t i = 0; i < msg.len; i++ ) {
    Serial.print(msg.buf[i], HEX); Serial.print(" ");
  } Serial.println();
  static uint32_t _time = millis();
  Serial.print("Time between frames: ");
  Serial.println(millis() - _time);
  _time = millis();
}

TeensyDuino 1.49
Arduino 1.8.9
 
OK. I hooked up two T4's using CAN3 with your provided code and everything worked properly.
Next, I changed the sending node to use CAN1 (in code and TX/RX wires) and it is back to unusual operation. Same weird timing occurs when sending on CAN2.

Code:
FIFO Enabled --> Interrupt Enabled
	FIFO Filters in use: 8
	Remaining Mailboxes: 8
		MB8 code: TX_INACTIVE
		MB9 code: TX_INACTIVE
		MB10 code: TX_INACTIVE
		MB11 code: TX_INACTIVE
		MB12 code: TX_INACTIVE
		MB13 code: TX_INACTIVE
		MB14 code: TX_INACTIVE
		MB15 code: TX_INACTIVE
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 13434 ID: E0 Buffer: 1 0 0 0 0 
Time between frames: 0
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 13529 ID: E0 Buffer: 2 0 0 0 0 
Time between frames: 1
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 30397 ID: E0 Buffer: 3 0 0 0 0 
Time between frames: 1999
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 30492 ID: E0 Buffer: 4 0 0 0 0 
Time between frames: 1
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 47360 ID: E0 Buffer: 5 0 0 0 0 
Time between frames: 1999
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 47458 ID: E0 Buffer: 6 0 0 0 0 
Time between frames: 1
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 64323 ID: E0 Buffer: 7 0 0 0 0 
Time between frames: 1999
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 64420 ID: E0 Buffer: 8 0 0 0 0 
Time between frames: 1
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 15750 ID: E0 Buffer: 9 0 0 0 0 
Time between frames: 1999
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 15845 ID: E0 Buffer: A 0 0 0 0 
Time between frames: 1
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 32713 ID: E0 Buffer: B 0 0 0 0 
Time between frames: 1999
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 32808 ID: E0 Buffer: C 0 0 0 0 
Time between frames: 1
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 49676 ID: E0 Buffer: D 0 0 0 0 
[COLOR="#FF0000"]Time between frames: 1999[/COLOR]
MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 49770 ID: E0 Buffer: E 0 0 0 0 
[COLOR="#FF0000"]Time between frames: 1[/COLOR]

Again, this just acts up when setMaxMB(10), so it is easy enough to avoid. The same code with setMaxMB(9) or setMaxMB(11) function fine.

Edit:
Arduino 1.8.11
Teensyduino 1.51
 
Last edited:
I wouldn't be surprised if it's a hardware bug since CAN peripherals on same chip behave differently, considering they're running the exact same legacy code, wanna try the github copy if you have time since you can test CAN1 and CAN2?
(github copy doesn't do interrupt transmits)
 
Github code acts exactly the same as Update7, CAN1 and CAN2 act weird when setMaxMB(10), but CAN3 operates correctly.
 
so i just tried the sketches tonton81 posted in #302 with my new Transceivers and it looks like they are working.

this is using a 4.1 to receive and a 4.0 to send and a nano to send (4.0 ID 0x740 and nano ID 0x608)
Code:
MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 59889 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 19401 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 44450 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 3964 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 101

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 29013 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 54064 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 13576 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

MB 99  OVERRUN: 0  LEN: 5 EXT: 0 RTR: 0 TS: 19330 ID: 740 Buffer: B4 0 0 0 0 

Time between frames: 23

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 38625 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 77

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 63673 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 101

MB 99  OVERRUN: 0  LEN: 8 EXT: 0 RTR: 0 TS: 23186 ID: 608 Buffer: 4F 87 32 FA 26 8E BE 86 

Time between frames: 100

CAN1.ECR.TX_ERR_COUNTER: 0

CAN1.ECR.RX_ERR_COUNTER: 0

CAN1.ESR1: 0x40080

i think i may have been getting false speed as it seems the old chips just constantly send out the same can frame on the rx pin if there is a problem with the bus
 
they can only transmit once and retry if they dont receive ACK. only your code can cause multiple sends, but in hardware, mailbox will send once only even if it retries, it stops when an ACK is present to confirm the bus received the packet

i would double check your nano code
 
the nano code is sending the same frame all the time so that's where the confusion was happening.

having tried with the old transceiver on the receiving teensy, if i unplug the USB power to the nano the teensy starts displaying the same frame on serial with a time of between 0 and 1 between frames.

if i do the same thing with the new transceiver all that happens is it disappears off the network and it just displays the 4.0 can data
 
Is there any reason why this might not work with MCP2562's?

My projects next iteration will probably have three CAN connections - one FD, two Classical - and I'd like to use DIP MCP2562's and MCP2562FD's instead of my current single MCP2558.
Has anyone tried those?
 
Hello

I am currently trying to filter messages using FIFO in Teensy 4.0.

Using the test tool, 14 CAN signals from ID:0x0FE to ID:10B were sent to Teensy.

Teensy wants to receive messages from ID:0x100 to ID:108, so
.setFIFOFilterRange(0, 0x100, 0x108, STD) was added.

Code:
#include "FlexCAN_T4.h"

FlexCAN_T4<CAN1, RX_SIZE_256, TX_SIZE_16> can1;

CAN_message_t msg;

void setup() {
  Serial.begin(921600);
  delay(1000);

  can1.begin();
  can1.setBaudRate(1000000);//1Mbps

  can1.enableFIFO();
  can1.enableFIFOInterrupt();
  can1.onReceive(FIFO, canSniff);
  can1.setFIFOFilter(REJECT_ALL);
  can1.setFIFOFilterRange(0, 0x100, 0x108, STD);
  can1.enhanceFilter(FIFO);

}

void loop() {
  can1.events();
  
}

void canSniff(const CAN_message_t &msg) {
  Serial.print("Interrupted ->");
  Serial.print("MB ");
  Serial.print(msg.mb);
  Serial.print(" OVERRUN: ");
  Serial.print(msg.flags.overrun);
  Serial.print(" LEN: ");
  Serial.print(msg.len);
  Serial.print(" EXT: ");
  Serial.print(msg.flags.extended);
  Serial.print(" TS: ");
  Serial.print(msg.timestamp);
  Serial.print(" ID: ");
  Serial.print(msg.id, HEX);
  Serial.print(" Buffer: ");
  for ( uint8_t i = 0; i < msg.len; i++ ) {
    Serial.print(msg.buf[i], HEX);
    Serial.print(" ");
  }
  Serial.println();
  
}

However, as for the actual received message, 11 messages from ID:0x100 to ID:10B are received as shown below.

Code:
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 147 ID: 10B Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 279 ID: 10A Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 530 ID: 100 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 656 ID: 105 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 782 ID: 104 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 908 ID: 103 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1033 ID: 102 Buffer: 0 0 0 0 0 0 0 0
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1284 ID: 106 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1410 ID: 107 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1536 ID: 109 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1660 ID: 101 Buffer: 0 0 0 0 0 0 0 0
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1786 ID: 108 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1911 ID: 108 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2036 ID: 101 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2162 ID: 10A Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2286 ID: 10B Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2410 ID: 105 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2536 ID: 100 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2789 ID: 109 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2913 ID: 102 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 3038 ID: 104 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 3164 ID: 103 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 3289 ID: 107 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 3541 ID: 106 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9043 ID: 106 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9355 ID: 101 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9481 ID: 108 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9606 ID: 100 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9732 ID: 105 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9858 ID: 10A Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 9982 ID: 10B Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10106 ID: 107 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10232 ID: 109 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10483 ID: 103 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10608 ID: 102 Buffer: 0 0 0 0 0 0 0 0 
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10733 ID: 104 Buffer: 0 0 0 0 0 0 0 0

If the filter is not used, all signals from ID:0x0FE to ID:10B sent from the test tool can be received normally.


Can you tell me what the cause is?
 
0xFE is less than 0x100, why do you expect it to pass the filter?

The filter (hardware) is doing exactly what it supposed to. The reason why your getting some frames above 0x108 (0x10B) is due to nature of masking multiple IDs. They're called bleed-through frames, because they match the mask due to the same bit differences. There is a sub-filter I put called can1.enhanceFilter(). Use that to sub filter the reception frame once the hardware passes it thru and only your exact selections will receive.

EDIT, I see you are using it. I'll check it later
 
Your code I am running right now and it IS running perfect AS IS with min 0x100 -> 0x108 max:

Code:
Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 24977 ID: 100 Buffer: 1 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 60441 ID: 101 Buffer: 2 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 30368 ID: 102 Buffer: 3 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 296 ID: 103 Buffer: 4 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 35760 ID: 104 Buffer: 5 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 5688 ID: 105 Buffer: 6 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 41152 ID: 106 Buffer: 7 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 11080 ID: 107 Buffer: 8 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 46544 ID: 108 Buffer: 9 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 62720 ID: 100 Buffer: 1 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 32648 ID: 101 Buffer: 2 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 2576 ID: 102 Buffer: 3 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 38040 ID: 103 Buffer: 4 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 7968 ID: 104 Buffer: 5 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 43432 ID: 105 Buffer: 6 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 13360 ID: 106 Buffer: 7 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 48823 ID: 107 Buffer: 8 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 18751 ID: 108 Buffer: 9 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 34927 ID: 100 Buffer: 1 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 4855 ID: 101 Buffer: 2 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 40319 ID: 102 Buffer: 3 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10247 ID: 103 Buffer: 4 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 45711 ID: 104 Buffer: 5 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 15639 ID: 105 Buffer: 6 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 51103 ID: 106 Buffer: 7 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 21031 ID: 107 Buffer: 8 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 56495 ID: 108 Buffer: 9 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 7134 ID: 100 Buffer: 1 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 42598 ID: 101 Buffer: 2 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 12526 ID: 102 Buffer: 3 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 47990 ID: 103 Buffer: 4 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 17918 ID: 104 Buffer: 5 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 53382 ID: 105 Buffer: 6 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 23310 ID: 106 Buffer: 7 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 58774 ID: 107 Buffer: 8 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 28702 ID: 108 Buffer: 9 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 44878 ID: 100 Buffer: 1 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 14805 ID: 101 Buffer: 2 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 50269 ID: 102 Buffer: 3 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 20197 ID: 103 Buffer: 4 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 55661 ID: 104 Buffer: 5 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 25589 ID: 105 Buffer: 6 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 61053 ID: 106 Buffer: 7 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 30981 ID: 107 Buffer: 8 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 909 ID: 108 Buffer: 9 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 17085 ID: 100 Buffer: 1 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 52549 ID: 101 Buffer: 2 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 22477 ID: 102 Buffer: 3 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 57941 ID: 103 Buffer: 4 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 27869 ID: 104 Buffer: 5 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 63333 ID: 105 Buffer: 6 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 33260 ID: 106 Buffer: 7 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 3188 ID: 107 Buffer: 8 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 38652 ID: 108 Buffer: 9 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 54828 ID: 100 Buffer: 1 6 6 6 6 6 6 6 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 24756 ID: 101 Buffer: 2 7 7 7 7 7 7 7 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 60220 ID: 102 Buffer: 3 0 0 0 0 0 0 0 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 30148 ID: 103 Buffer: 4 1 1 1 1 1 1 1 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 76 ID: 104 Buffer: 5 2 2 2 2 2 2 2 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 35540 ID: 105 Buffer: 6 3 3 3 3 3 3 3 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 5468 ID: 106 Buffer: 7 4 4 4 4 4 4 4 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 40932 ID: 107 Buffer: 8 5 5 5 5 5 5 5 

Interrupted ->MB 99 OVERRUN: 0 LEN: 8 EXT: 0 TS: 10860 ID: 108 Buffer: 9 6 6 6 6 6 6 6

Please verify you are running the github copy, the one in TeensyDuino may be outdated.

Without enhanced filters, you will receive min 0x100 -> 0x10B max. (possibly more depending on the mask, transmitting up to 0x120 will result in IDs 0x100 to 0x10F, normal mask behaviour. enhancement on will bring it down to 0x100 and 0x108.)
 
Last edited:
Thank you for checking.


I installed the library again with the following steps, but the result did not change.

(1) Already installed
C:\Program Files (x86)\Arduino\hardware\teensy
Delete all folders

(2) Download and install Teensyduino Version 1.52 from PJRC official website (Arduino IDE uses Version 1.8.12)

(3) Write the same code as before to Teensy
└> Result: Failure (same as before)

(4) Download FlexCAN_T4-master.zip from the github URL at the top of this forum.

(5) Menu of Arudino IDE Sketch> Include Library> Select FlexCAN_T4-master.zip downloaded .ZIP format library from Include

(6) Restart Arudino IDE and write the code to Teensy
└> Result: Failure (same as before)


I tried several kinds of filter range changes.
I am using .enhanceFilter(FIFO) and it seems that the filter is not working properly.
FIFO TEST.png

If you have any other possible causes, I would appreciate it if you could give me some advice.
 
I have applied the patch that you taught me.

As a result, the filter is now working properly!
Thank you very much!

I'm curious, but this time I applied the patch to C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FlexCAN_T4.

Will the patched location change the next time I update my Teensyduino?
 
the github copy will always be latest, except the patch which is in testing phase on this thread for stability since it introduced transmit interrupt transfers and also able to function directly with interrupts rather than handling them in loop(). there were also other additions like custom masks support (CAN2.0 only), loopback support, etc

if you put the github copy with patch in your Documents/Arduino/libraries folder, the IDE will use that as priority before using the core version, so updating the IDE and TeensyDuino won't affect your local copy

Probably if the latest patch update is stable by next week I will archive the github version and update those 2 files. So far, other than msadie's issue regarding an inbox count transmit issue (which seems like a hardware bug), the update looks good so far.

Also msadie, the CAN3 controller is an updated version of the other 2 legacy controllers, so they probably fixed that issue in the new controller that they neglected in the older ones. Something to think about, almost all generations of NXP with the 2.0 flexcans have the exact same "erratas", as if they don't resolve it when making new processors.....

Heck, flexcan CAN3 FD had an undocumented errata that we stumbled upon, not having any of the lpuart clocks enabled caused it to hard fault the cpu on startup :p
 
Last edited:
Interesting. Looks like the imxrt1170 is targeting 3x CAN FD modules and ditching the FlexCAN 2.0, so at least that minor bug mailbox will be resolved.
 
I put the previous flexcan in a branch of the repo "before-TX-interrupts"

Update7 has been applied to "master" branch, so no need to patch it anymore.
 
Can anyone suggest the best rout to implement the following behaviour with the SN65HVD230?

I want the transceiver to be in low power mode by default, which means I need to pull the Rs pin to Vcc (3.3v) and once the Teensy starts up I want to pull the Rs pin low (GND or as low as possible) via a digital PIN and go into high speed mode or slope control mode.

I was thinking of connecting Rs to Vcc as well as to a digital pin via a 4.7k resistor like so:
Screen Shot 2020-07-05 at 20.50.54.png

Is this the right way or should I change it up?
 
I think the resistor needs to be on the vertical branch to the 3.3v. This would weakly pull-up Rs, and then could be easily pulled low by the T4 digital out. A possible issue I'm not sure about is if the Rs pin has internal pull-up or pull-down biasing worth considering.
 
better to have it hard wired than in code, pins go hi impedance when the MCU is disconnected, rebooted, or reprogrammed. If a state needs to be enforced when the MCU is unavailable, a resistor is definately required to maintain the default state, especially if using a fail-safe
 
I think the resistor needs to be on the vertical branch to the 3.3v. This would weakly pull-up Rs, and then could be easily pulled low by the T4 digital out. A possible issue I'm not sure about is if the Rs pin has internal pull-up or pull-down biasing worth considering.
You're correct on the resistor, I found a dev board with a 230 in the circuit and the schematic did show a 22k resistor between 3v3 and Rs, and another 10k resistor between Rs and a digital pin for enable with slope control.
Screen Shot 2020-07-06 at 11.35.48.png
I think Rs has pull-up biasing based on the block diagram on the first page of the datasheet.

better to have it hard wired than in code, pins go hi impedance when the MCU is disconnected, rebooted, or reprogrammed. If a state needs to be enforced when the MCU is unavailable, a resistor is definately required to maintain the default state, especially if using a fail-safe
The T4s "off" state will only be in hibernate. In that case, most of the pins are either disabled or configured as inputs to keep current consumption down - I think I'll just have to play with multiple setups and configurations to find the sweet spot
 
Hello, I have a very low power servo motor drive that can be commanded by CANopen and RS485 and i do realize that CANopen is a protocol layer / standard, but i am wondering if anyone has any experience with CANopen with this library?

using a RS485 method of control i was able to put the drive into an operation state and command its position. (example sequence below using RS485)

servo.write(0x6060, 0x0, 1L); // Send "Shutdown command" to enter in Ready to "Switch on"
servo.write(0x6040, 0x0, 6L); // Send "Switch on command" to enter in "Switch on"
servo.write(0x6040, 0x0, 7L); // Pre-operational state
servo.write(0x6040, 0x0, 15L); // Send "Enable operation command" to enter in "Operation Enable"

My question is :-
Would it be an option to 'simply' use the myCan.Write function to write the same messages to the drive ?
myCan.write(0x6060, 0x0, 1L); for example?

I am hesitant for blindly trying for a number of reasons, but the main reason is i know a great deal more people understand the subtleties of CAN better than me, so i dont want to damage the drive over my lack of understanding.
and the potential upshot of this would be the only answer on the web that would relate to a Micro controller putting a CANopen drive into operation mode without a custom CANopen Stack.

If my time using this drive might be useful to the community then please let me know. as i am more than happy to post code i get working / as i work through any issues.

I am using a teensy 3.6
 
Back
Top