Search:

yup you are correct the tdie bit on the 1062 is used because there was an issue using the rdie. i dont remember what but it took a long time to work out the kinks and qwirks just to get it stable...

try enabling the interrupt at the end. whenever you set a MB the filters and interrupts reset.

you already posted this as an issue on github. Don't set a filter then configure the mailbox. That is backwards. also post what mailboxStatus() shows

just load master on one and slave on the other, if you dont see communication try swapping the MISO/MOSI lines around

make sure Teensy 4.1 is selected in arduino if not already done for that error

also do not use the GND pin located next to pin 0, you need to have both 4.1s connected with the GND pin located next...

1) it should provided the payload is 6 bytes or less, provided the first 2 bytes are passes as an isotp header. if you prefer not receiving those single frames whivh can exist during debugging, i...

yes send both as normal frames, the isotp is there just to assemble messages in stream

you need to send that frame, then send the flow control after, if you don't send the flow control frame the ecu will not send out the full isotp frame, and if the full isotp frame is not sent out you...

effectively that writes the 8 bytes as a payload in isotp format (2 frames for payload)

so, 8 bytes as payload plus isotp header
to send that just as a frame itself use Can1.write(msg)

this is just an example of sending and receiving, you can change it up to your purpose as needed

the hardware retransmits automatically, even if you call an abort on the mailbox it may or may not transmit a garbage frame, and if your code is retransmitting over a loop you'll just be enabling it...

have you tried swapping around the MISO and MOSI wires?

can you try SPI_MSTransfer_T4 library example, that should work just for sanity check, because if it doesn't, it's most likely a connection or cross-wire issue.
check if the demo works on both your...

yes that will work, you could also just send it 10ms after the request

isotp server acts same way like ecu

ahh i see. the way the library handles isotp between teensies is it sends the complete isotp frames. So for reception that is not complete, an isotp first frame is discarded if overridden as needed...

isotp plugin doesn't use mailboxes specifically, as the data comes in it from the controller goes to the background reassembly queue until it is complete, until which it it then fires the user...

the isotp is an addon, you can use both as needed in same sketch

well thats for isotp.

for pid requests you can just use the following (edited as needed)



CAN_message_t msg;
msg.id = random(0x1,0x7FE);
for ( uint8_t i = 0; i < 8; i++ )...

it all depends on how long your interrupts are, and the speeds of the SPI obviously especially when pushing data. if the slave interrupt is not ready to receive because of another interrupt you may...

this library setups only one LPSPI as slave. Even if you managed to setup 2 or more slave on LPSPI you'd need to be able to manage the 2 ports simuletaneously, and if interrupts are involved, good...

that wouldnt be possible, u cant have 2 masters talking to one slave,

2 slaves? use 1 or 2 SPI ports on master should work, the slave is fixed only to one bus

its one byte/word at a time, not grouped. if you want the slave to send more data you need to basically send dummy bytes/words to push the data out of the slave, so you need to handle that as needed

yes but the master end *should* work on any other arduinos, you'd have to test as it uses the standard SPI library for master. The slave end is only working for the Teensy 3.x/LC/T4.x end. The patch...

SPI_MSTransfer_T4 is a 2-way daisy-chainable data transfer utility. It includes the slave and master headers and source files, with simple examples.

if you prefer to keep a teensy4.x as master...

if you are using a T4.x master there is a slight bug in the DSE gpio bits, which is fixed in SPI_MSTransfer_T4. Other master controllers don't seem to have this issue. Also for your common ground...

what i always do (my own preference of course) is setup a scoped millis() near the action you want to do, so in the loop i would put:



void loop() {
static uint32_t coolant_timer = millis();...

you shouldn't need to strip mailboxes down to one using msg.seq = 1, it will only output to the absolute first mailbox. also you don't need events() in loop if you want direct firing interrupts, but...

are you using pins 0 & 1 for CAN2?
are you using level shifters? teensy is 3.3v
is the Rs pin driven low?

only thr t4.x masters needs specific dse bits set, other masters work fine

the master 4.x need a patch for the DSE bits, check out the commits for SPI_MSTransfer_T4, this only affects the master, just make sure your ground is the one next to the 5v pin (not near pin 0)

Hardware only sends transmission once but only if it is successful. It will retry until a valid ACK occurs and then it can continue to next frame. Be sure a node is on the bus to ACK it and check the...

i don't see POPR used in your last code, both of them must be used. if you dont care for POPR (receiving) then flush it at very least:


(void)mySPI.popr();

for the 4.x slave check if you're using the GND beside the 5v pin, and not the one beside pin 0

there is no buffer, this is a fixed register in the SPI hardware
POPR receives byte from bus master...

Is there any data on the bus? If it's in a TX mailbox it should be writing out, what does mailboxstatus print out?

thats the master, have you tried the master slave examples as a start to make sure your wiring is okay? the examples do work so they will rule out if it's a software or hardware connection issue

do a mailboxStatus(), if it still stays there after you stop transmitting, verify your baudrate, terminations, transceiver connections. it will stay in the mailbox and software has no control over...

each hardware mailbox stores only one frame during poll mode. if you use interrupts, a queue system automatically collects the mailboxes so they can receive another frame. From that queue, the...

still that error makes no sense if you have it set to teensy T4.x. maybe its because it's a french IDE having incompatibilities with teensyduino? nothing in the library is avr related

is that the only method you need working? if so, you can temporarily add it as a virtual method in FlexCAN_T4_Base class (virtual method(args) = 0) and it will work until i figure out a template...

You can use the base class as an alternative




FlexCAN_T4<CAN1, RX_SIZE_256, TX_SIZE_16> Can0;

class TestClass {
private:
FlexCAN_T4_Base* bus = nullptr;

I wrote a post regarding using template objects, it just replicates your function for X busses without doubling it in the sketch.
...

same device? well i would imagine the interrupt being held open with active locked, the loop wouldnt be able to send anything until that's done, i never tested it as a loopback but thats where you...

yes, latest always on github for any library

never heard of that error before, make sure you have teensy selected as the board

should be the arduino/libraries folder, not the main project location

if thats the 4.1, could you try the GND on the other side of the board, not the one next to pin 0

try 2.2k resistors instead of 4.7k for 3.3v i2c

I can't see all your code but just remove events() from the loop() if you have it so the callback will fire directly rather from the events() queue system, this will disable the RX queue system and...