FLEXCAN_T4 FD ISSUE
@PaulStoffregen - @skpang - @tonton81
Very strange solution to the problem reported in post #25.
Turned PRINT_DEBUG_STUFF back on and FlexCAN_t4 FD mode runs fine as well as my SDK example!:
wasisCode://#define PRINT_DEBUG_STUFFCode:#define PRINT_DEBUG_STUFF
Very cool to see this developed and working tonton81!
@mjs513 - any chance without the PRINT_DEBUG_STUFF this works when debug_tt is added? That might point to the work Paul plans to do on the reset_handler().Originally Posted by mjs513
Without any explicit calls to the debug I can only imagine - like debug_tt inclusion - this just shifts code/memory/segments locations around in some unique way.
Or it could be the .tpp somehow adds some dynamic CPP machinations that are done too early in startup process for the FD setup versus the CAN2 and that PRINT_DEBUG_STUFF better accommodates.
@defragster
To be honest didn't think about inserting debug_tt to see what happensWas concentrating on figuring out what was causing the hangup and going through the core commits to see what was causing the problem that didn't think that far.
Don't think it the .tpp files since CAN2.0 uses .tpp files as well. But then again who knows.
Think its some strange memory shifting going on
@defragster
I gave your debug_tt a try but nothing happened when DEBUG_PRINTF is disabled - the sketch just goes into an infinite loop telling me register hasn't changed - when I enable debug_printf it works but with debug_tt an fault is thrown and the LED flashes rapidly:
Code:D:\Users\Merli\Documents\Arduino\T4\Flexcan_t4\Flexcan_sdk4_NodeB\Flexcan_sdk4_NodeB.ino Aug 26 2019 18:53:31 ******** T4 connected Serial_tt ******* debug_tt port D:\Users\Merli\Documents\Arduino\T4\Flexcan_t4\Flexcan_sdk4_NodeB\Flexcan_sdk4_NodeB.ino Aug 26 2019 18:53:31 >>> Reason for 'reset': 1 IPP_RESET_B :: done Reason F_CPU==600000000 F_BUS==150000000 FreeMem(); 4293328788 CCM_CSCMR2: 13192E0E CCM_CCGR7: FFFFFFFF Core pin 30 done Core pin 30 done Core pin 30 done 0 ********* FLEXCAN Interrupt EXAMPLE ********* Message format: Standard (11 bit id) Message buffer 10 used for Rx. Message buffer 9 used for Tx. Interrupt Mode: Enabled Operation Mode: TX and RX --> Normal ********************************************* Registers on startup MCR ---- 5980000f CTRL1 ---- 0 TIMER ---- 0 IMASK1 ---- 0 IFLAG1 ---- 0 IFLAG2 ---- 0 CTRL2 ---- 800000 ESR2 ---- 0 CRCR ---- 0 FDCTRL ---- 80000100 Stuck in FALSE Stuck in TRUE MCR ---- a0080f CTRL1 ---- 25a2021 TIMER ---- 9 IMASK1 ---- 0 IFLAG1 ---- 0 IFLAG2 ---- 0 CTRL2 ---- b30000 ESR2 ---- 6000 CRCR ---- 0 FDCTRL ---- 80008300 Start to Wait data from Node A Fault irq 170 stacked_r0 :: 00000000 stacked_r1 :: 00000000 stacked_r2 :: 00000000 stacked_r3 :: 00000000 stacked_r12 :: CC080000 stacked_lr :: 401D8080 stacked_pc :: 00001282 stacked_psr :: 61010000 _CFSR :: 00000000 _HFSR :: 00000000 _DFSR :: 00000000 _AFSR :: 00000000 _BFAR :: 00000000 _MMAR :: 00000000 debug_tt (weak) default :: customize with 'void Debug_Dump()' in user code. userDebugDumptt() in debug_tt ___ F_CPU=300000000 >>>> Debug Fault >>>> debug_fault >>>> TYPE:T_4 debug_tt Info: >>>> Debug Fault >>>> TYPE:T_4 --- Faulted >>>> Execution Halted. For more info - print it in sketch :: Debug_Dump(void)
Just as well it didn't fix it just adding the debug_tt- it is unknown side effect so wouldn't explain anything.
Very good though that debug_tt did bring the FAULT to life! Is that using the last stuff I left on github?
Sad to say I've never revisited testing working with it with the PJRC_Beta fault and debug print removed .
@mjs513 - it seems the ftrias GProt code does a stack back trace that could be helpful to include if it got good func ref #'s to dig from the linker map.
I wonder if there is anything useful that could be printed in sketch local function : void userDebugDumptt() {}
Does the irq # 170 relate to the code in any way?
@defragster - think its the latest - may have missed an update.
was thinking about gprot for a while since I saw - there are a lot of changes to make it work to platforms, startup etc that I am not ready to make while we are still fixing things - didn't want to add another layer of confusion or source of potential problem.
Interesting on the IRQ number - thought it only went up to 160!
I have not updated it in some time - my last touch on the local files was to try to tear it down to start with a minimal fresh start - so interesting to know if what is there was what worked for you - as local code may be a mess.
Then I threw all that aside when T4 released to make sure I didn't anything in sketchbook\libraries that would confused the 1.47 build.
Wow - somebody studied the code a bit "#define NVIC_NUM_INTERRUPTS 160" - so not sure what 'HAT' that number 170 was pulled from.
My thought for gprot was - abuse/incorporation of its code - to yank out the Stack Back Trace. I think I found the code - where it notes clearing the thumb bit. Might be a fun add to debug_tt - but limited value without tying it to link build data.
Adding
Didn't work for me. It still doesn't get past FD.begin() but I'm using 1.47Code:#define PRINT_DEBUG_STUFF
AFAIK @mjs513 is referring to this to enable - removing the comment:
Code:{Arduino...}\hardware\teensy\avr\cores\teensy4\debug\printf.h: 1: // #define PRINT_DEBUG_STUFF
Ok, removing the comment and recompile got past the FD.begin().
I can see data on the CTX3 line but can't work out what bit rate it is. From a scope I see the arbitration bit rate is 1us and data is 500ns that should give 500kbps for arbitration and 2mbps for data but on the CAN-bus analyzer it is giving Error Passive warning.
@skpang
If you look through the lib there seem to be a couple of commands that may work - haven't tested though:
That may help.Code:uint32_t getBaudRate() { return currentBitrate; } void setBaudRate(uint32_t baud = 1000000);
skpang the bitrate is hardcoded to match what the sdk is using by default. There is no baudrate calculation yet for flexcan_t4, still work to do, setbaudrate is unused currently until then
@Paul - @defragster - @tonton81 - @skpang
While further working on the FlexcanFD library @tonton81 came across a chip problem with Flexcan that will prevent it from working unless the LPUART module clock is enabled: Is FlexCAN3 (CAN-FD) dependent on LPUART module clock?.
Their solution was to make sure its enabled when using Flexcan. This issue is why when Debug_printf is enabled it will work, i.e., debug_printf enables the LPUART. As a test and what we are going to put in the lib is simply:
.Code:CCM_CCGR0 |= CCM_CCGR0_LPUART3(CCM_CCGR_ON); // turn on Serial4
We tested this with our FD example sketches and it works with debug_printf turned off.
Interesting dependency - always funny when DEBUG/WIP inadvertently makes things work and then going live a mystery pops up. Good to know ...
@defragster
@tonton81 found the issue by accident when he was searching for something else on the NXP Community site. NXP even admitted its a bug in the chip.
Is FD only available on 30/31 or can it be MUXed to physical pins 0/1, 22/23?
Only on the inconvenient bottom-side pins 30/31.
Hi all - just recently bought a Teensy 4.0 to start testing and working on moving my CANBUS projects to this platform. Have currently been running with a few different platforms - Arduino Pro Mini with MCP2515 Can Controllers (SLOW!), ESP32s, and Arduino Due's. The performance of the T4 and 3 can controller built in is going to be nice! I'm using CAN2.0 with Extended IDs, so no need for FD for me.
Couple questions/comments about the library.
First - in the lastest version, I found that the writeTXMailbox function was modified and the original is commented out. I had to swap them and re-enable the 2nd one to make it work. Was there a reason for that, or just some testing?
Second - It took me a while to figure out, but it was not sending Extended frames correctly. I figured out what was missing and added it to my code. Just needed the line that sets the extended flag in the msg ID. Before it would send as a standard, even if you set the flag when setting up the message.Code:FCTP_FUNC void FCTP_OPT::writeTxMailbox(uint8_t mb_num, const CAN_message_t &msg) { writeIFLAGBit(mb_num); // 1st step clear flag in case it's set as per datasheet ( msg.flags.remote ) ? FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_RTR : FLEXCANb_MBn_CS(_bus, mb_num) &= ~FLEXCAN_MB_CS_RTR; //FLEXCANb_MBn_CS(_bus, mb_num) = (1UL << 31); // FD frame FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_LENGTH(msg.len+7); FLEXCANb_MBn_WORD0(_bus, mb_num) |= 0x55555555; //FLEXCANb_MBn_WORD1(_bus, mb_num) |= 0x55555555; //FLEXCANb_MBn_WORD2(_bus, mb_num) |= 0x55555555; // for ( uint8_t i = 0; i < msg.len; i++ ) ( i < 4 ) ? (FLEXCANb_MBn_WORD0(_bus, mb_num) |= (*(msg.buf + i)) << ((3 - i) * 8)) : (FLEXCANb_MBn_WORD1(_bus, mb_num) |= (*(msg.buf + i)) << ((7 - i) * 8)); //for ( uint8_t i = 0; i < 8; i++ ) FLEXCANb_MBn_DATA(_bus, mb_num, i) = 0x55555555; FLEXCANb_MBn_ID(_bus, mb_num) = (( msg.flags.extended ) ? ( msg.id & FLEXCAN_MB_ID_EXT_MASK ) : FLEXCAN_MB_ID_IDSTD(msg.id)); FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_ONCE); if ( msg.flags.remote ) { uint32_t timeout = millis(); while ( !(readIFLAG() & (1ULL << mb_num)) && (millis() - timeout < 10) ); writeIFLAGBit(mb_num); FLEXCANb_MBn_CS(_bus, mb_num) = FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_INACTIVE); } } /* FCTP_FUNC void FCTP_OPT::writeTxMailbox(uint8_t mb_num, const CAN_message_t &msg) { writeIFLAGBit(mb_num); // 1st step clear flag in case it's set as per datasheet ( msg.flags.remote ) ? FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_RTR : FLEXCANb_MBn_CS(_bus, mb_num) &= ~FLEXCAN_MB_CS_RTR; FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_LENGTH(msg.len); FLEXCANb_MBn_WORD0(_bus, mb_num) = FLEXCANb_MBn_WORD1(_bus, mb_num) = 0; for ( uint8_t i = 0; i < msg.len; i++ ) ( i < 4 ) ? (FLEXCANb_MBn_WORD0(_bus, mb_num) |= (*(msg.buf + i)) << ((3 - i) * 8)) : (FLEXCANb_MBn_WORD1(_bus, mb_num) |= (*(msg.buf + i)) << ((7 - i) * 8)); FLEXCANb_MBn_ID(_bus, mb_num) = (( msg.flags.extended ) ? ( msg.id & FLEXCAN_MB_ID_EXT_MASK ) : FLEXCAN_MB_ID_IDSTD(msg.id)); FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_ONCE); if ( msg.flags.remote ) { uint32_t timeout = millis(); while ( !(readIFLAG() & (1ULL << mb_num)) && (millis() - timeout < 10) ); writeIFLAGBit(mb_num); FLEXCANb_MBn_CS(_bus, mb_num) = FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_INACTIVE); } } */
I'm no expert, so there may be more that is needed, but it all appears to be working for now! Looking forward to working with this library! These boards have a lot of potential!Code:FCTP_FUNC void FCTP_OPT::writeTxMailbox(uint8_t mb_num, const CAN_message_t &msg) { writeIFLAGBit(mb_num); // 1st step clear flag in case it's set as per datasheet ( msg.flags.remote ) ? FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_RTR : FLEXCANb_MBn_CS(_bus, mb_num) &= ~FLEXCAN_MB_CS_RTR; FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_LENGTH(msg.len); if (msg.flags.extended) FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_IDE; FLEXCANb_MBn_WORD0(_bus, mb_num) = FLEXCANb_MBn_WORD1(_bus, mb_num) = 0; for ( uint8_t i = 0; i < msg.len; i++ ) ( i < 4 ) ? (FLEXCANb_MBn_WORD0(_bus, mb_num) |= (*(msg.buf + i)) << ((3 - i) * 8)) : (FLEXCANb_MBn_WORD1(_bus, mb_num) |= (*(msg.buf + i)) << ((7 - i) * 8)); FLEXCANb_MBn_ID(_bus, mb_num) = (( msg.flags.extended ) ? ( msg.id & FLEXCAN_MB_ID_EXT_MASK ) : FLEXCAN_MB_ID_IDSTD(msg.id)); FLEXCANb_MBn_CS(_bus, mb_num) |= FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_ONCE); if ( msg.flags.remote ) { uint32_t timeout = millis(); while ( !(readIFLAG() & (1ULL << mb_num)) && (millis() - timeout < 10) ); writeIFLAGBit(mb_num); FLEXCANb_MBn_CS(_bus, mb_num) = FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_INACTIVE); } }
Tom
the T4 flexcan library is in development stages so it’s been being rewritten off it’s older IFCT counterpart to be working with the T4 hardware, FD is currently being worked on CAN2.0 will be returned to later on, you may refer to the snippets from IFCT for corrections, however, the t4 version was being in test stages that period for remote frames capability, thats why it’s a bit mixed up. The duplicate you seen was just reference during modifications during testing
That is kind of what i figured - I think i have it working enough for my requirements at the moment. I will definitely keep an eye on the library as your work progresses. I will attempt to contribute when possible! Thanks!
FD is up for testing! Big update!
Sorry guys I have been busy for months but I never give up on this
I spent time on doing text-like graphs for the new baudrate generator in FlexCAN_T4FD.
According to NXP, after they tested, advertised, and documented it as having FD FIFO, they now claim that the 1062 does NOT have FD FIFO, only mailbox support. So throwing it out here in case FIFO is questioned, it is NOT supported.
There are big changes to the way the library operates, it is more efficient and faster redesign implementation of IFCT. (Take what you learn and make it better, right?
Sketch:
1) The clocks and bitrates are set by the red region in the sketch posted above. You have full control of the baudrates for nominal, data, length of bus, propagation delay of transceiver, and what clock you want to use.Code:#include <FlexCAN_T4.h> FlexCAN_T4FD<CAN3, RX_SIZE_256, TX_SIZE_16> FD; void setup(void) { Serial.begin(115200); delay(500); pinMode(6, OUTPUT); digitalWrite(6, LOW); FD.begin(); CANFD_timings_t config; config.clock = CLK_24MHz; config.baudrate = 1000000; config.baudrateFD = 2000000; config.propdelay = 190; config.bus_length = 1; config.sample = 87.5; FD.setBaudRate(config, 1, 1); FD.onReceive(canSniff); FD.setMBFilter(REJECT_ALL); FD.setMBFilter(MB22, ACCEPT_ALL); FD.setMBFilter(MB0, 0x8); FD.setMBFilter(MB12, 0x1, 0x04); FD.setMBFilterRange(MB13, 0x1, 0x04); FD.enableMBInterrupt(MB12); FD.enableMBInterrupt(MB13); FD.mailboxStatus(); FD.enhanceFilter(MB12); FD.enhanceFilter(MB13); FD.distribute(); } void canSniff(const CANFD_message_t &msg) { Serial.print("ISR - 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(); } void loop() { FD.events(); /* needed for sequential frame transmit and callback queues */ CANFD_message_t msg; msg.len = 8; msg.id = 0x321; msg.seq = 1; msg.buf[0] = 1; msg.buf[1] = 2; msg.buf[2] = 3; msg.buf[3] = 4; msg.buf[4] = 5; msg.buf[5] = 6; msg.buf[6] = 9; msg.buf[7] = 9; FD.write( msg); if ( FD.read(msg) ) { bool prnt = 1; if ( prnt ) { Serial.print("MB: "); Serial.print(msg.mb); Serial.print(" OVERRUN: "); Serial.print(msg.flags.overrun); Serial.print(" ID: 0x"); Serial.print(msg.id, HEX ); Serial.print(" EXT: "); Serial.print(msg.flags.extended ); Serial.print(" LEN: "); Serial.print(msg.len); Serial.print(" DATA: "); for ( uint8_t i = 0; i < 8; i++ ) { Serial.print(msg.buf[i]); Serial.print(" "); } Serial.print(" TS: "); Serial.println(msg.timestamp); } } delay(25); }
1000/6000 was tested by skpang on his analyzer using CLK_60MHz.
2) Automatic Filtering support! - More efficient, More faster than previous implementation! Mask? What mask? Put your ID and your all set!
3) Smart filtering support! - More efficient, More faster than previous implementation! Stop those bleed-thru frames in a multi/range setup mailbox mask!
4) Distribution support! - Having mailbox 13 capture 2 can ids only? CAN ID 0x1 and 0x4, and mailbox 14 capture can ids range based from 0x2-0x5? Heads up, Your second callback won't fire because the hardware is designed to drop it into ONLY one. So ID 0x04 will ONLY goto mailbox 13, and not 14. With distribution support, all overlapping filter callbacks with a match will get a copy!
5) Change the region sizes of your memory blocks! Want 8, 16, 32 or 64 bytes data for send/receive? The bigger the data, the less amount of mailboxes you'll have. No problem for the library to handle! FD.setRegions(64); sets 14 mailboxes with 64 bytes data!
6) Callback and CBA queue support! More optimized, faster than previous implementation
7) Direct mailbox offset support, unlike the SDK running hundreds of thousands of divisions in a constant poll/isr for mailbox access, FlexCAN_T4 accesses it using a different calculation method, division is NOT required to get to the mailbox ram location!
8) Sequential frame support with ability to resend should the mailbox be busy! Keep your frames in-order!
PS: Thanks Paul and Robin for getting me the hardware needed to get this setup needed to work with and mjs513 for the SDK code I can work against.
Github has been updated! (Note, This is the FD side I'm working on, I will adapt the optimisations later to the CAN2.0 side once things are running good on FD end)
https://github.com/tonton81/FlexCAN_T4/
Last edited by tonton81; 09-30-2019 at 01:48 AM.
@tonton81
Nice job especially with the timings. I just gave it a quick test. I put the sketch you posted on one T4 and this sketch on the other:
On the T4 in your post I am seeing:Code:#include <FlexCAN_T4.h> FlexCAN_T4FD<CAN3, RX_SIZE_256, TX_SIZE_16> FD; uint32_t CLOCK = 20000000; void setup(void) { Serial.begin(115200); delay(500); pinMode(6, OUTPUT); digitalWrite(6, LOW); FD.begin(); CANFD_timings_t config; config.clock = CLK_24MHz; config.baudrate = 1000000; config.baudrateFD = 2000000; config.propdelay = 190; config.bus_length = 1; config.sample = 87.5; FD.setBaudRate(config, 1, 1); Serial.println("\n\n\n\n"); FD.onReceive(canSniff); } void canSniff(const CANFD_message_t &msg) { Serial.print("- MB "); Serial.print(msg.mb); 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(); } bool sett = 1; void loop() { if ( sett ) { sett = 0; FD.setMBFilter(REJECT_ALL); FD.setMBFilter(MB12, ACCEPT_ALL); FD.setMBFilter(MB22, ACCEPT_ALL); FD.setMBFilter(MB0, 0x8); FD.setMBFilterRange(MB3, 0x1, 0x03); FD.enableMBInterrupt(MB3); } CANFD_message_t msg; msg.len = 8; msg.id = 0x321; msg.buf[0] = 1; msg.buf[1] = 2; msg.buf[2] = 3; msg.buf[3] = 4; msg.buf[4] = 5; msg.buf[5] = 6; msg.buf[6] = 9; msg.buf[7] = 9; FD.write(MB49, msg); if ( FD.read(msg) ) { bool prnt = 1; if ( prnt ) { Serial.print("MB: "); Serial.print(msg.mb); Serial.print(" OVERRUN: "); Serial.print(msg.flags.overrun, HEX ); Serial.print(" ID: 0x"); Serial.print(msg.id, HEX ); Serial.print(" EXT: "); Serial.print(msg.flags.extended ); Serial.print(" LEN: "); Serial.print(msg.len); Serial.print(" DATA: "); for ( uint8_t i = 0; i < 8; i++ ) { Serial.print(msg.buf[i]); Serial.print(" "); } Serial.print(" TS: "); Serial.println(msg.timestamp); } } delay(25); msg.id = 0x1; FD.write( msg); delay(25); msg.id = 0x4; FD.write( msg); delay(25); msg.id = 0x2; FD.write( msg); delay(25); msg.id = 0x8; FD.write( msg); delay(25); }
Just as its suppose to beCode:MB: 0 OVERRUN: 0 ID: 0x8 EXT: 0 LEN: 8 DATA: 1 2 3 4 5 6 9 9 TS: 4622 ISR - MB 12 OVERRUN: 0 LEN: 8 EXT: 0 TS: 11223 ID: 1 Buffer: 1 2 3 4 5 6 9 9 ISR - MB 13 OVERRUN: 0 LEN: 8 EXT: 0 TS: 11223 ID: 1 Buffer: 1 2 3 4 5 6 9 9 ISR - MB 12 OVERRUN: 0 LEN: 8 EXT: 0 TS: 47250 ID: 4 Buffer: 1 2 3 4 5 6 9 9 ISR - MB 13 OVERRUN: 0 LEN: 8 EXT: 0 TS: 17798 ID: 2 Buffer: 1 2 3 4 5 6 9 9 MB: 0 OVERRUN: 0 ID: 0x8 EXT: 0 LEN: 8 DATA: 1 2 3 4 5 6 9 9 TS: 53963 ISR - MB 12 OVERRUN: 0 LEN: 8 EXT: 0 TS: 60564 ID: 1 Buffer: 1 2 3 4 5 6 9 9 ISR - MB 13 OVERRUN: 0 LEN: 8 EXT: 0 TS: 60564 ID: 1 Buffer: 1 2 3 4 5 6 9 9 ISR - MB 12 OVERRUN: 0 LEN: 8 EXT: 0 TS: 31199 ID: 4 Buffer: 1 2 3 4 5 6 9 9 ISR - MB 13 OVERRUN: 0 LEN: 8 EXT: 0 TS: 1659 ID: 2 Buffer: 1 2 3 4 5 6 9 9
On short cable run, it is working at 1000/8000kbps is well.
Hi all,
I'm currently testing the CAN bus with this library and a Teensy4 + SN65HVD230 as a transceiver.
I want to establish a communication between two teensy4 via CAN. My setup is a following :
- One T4 sending a 8 bytes data CAN packet, with ID and byte[0] incremented after each sending
- One T4 receiving the data.
The ID is correctly received, but the data remains constant, not the same as send, and not with the good size (len field of CAN_message_t is 15, instead of 8 [11 for a len of 4]).
Below the (merged code) -- sender & received.
Is there a known issue ?Code:#include <FlexCAN_T4.h> FlexCAN_T4<CAN1, RX_SIZE_256, TX_SIZE_16> Can1; CAN_message_t msg; CAN_message_t inMsg; // ------------------------------------------------------------- void setup(void) { Serial.begin(115200); Can1.begin(); Can1.setBaudRate(250000); msg.len = 8; msg.buf[0] = 0x00; msg.buf[1] = 0x01; msg.buf[2] = 0x02; msg.buf[3] = 0x03; msg.buf[4] = 0x04; msg.buf[5] = 0x05; msg.buf[6] = 0x06; msg.buf[7] = 0x07; } void print_msg(CAN_message_t toto) { Serial.print("Message id "); Serial.println(toto.id); for(uint8_t i = 0 ; i< toto.len;i++) { Serial.print(toto.buf[i]); Serial.print("\t"); } Serial.println(); } // ------------------------------------------------------------- void loop(void) { /* SENDER PART Can1.write(msg); msg.id++; msg.buf[0]++; delay(100); */ while(Can1.read(inMsg)) { Serial.println("CANtest - Read bus1"); print_msg(inMsg); } }
Many thanks,
Last edited by ghae; 10-01-2019 at 10:26 AM.
There are still bugs in the library due to it being in development, currently CANFD portion is being progressed until it is stable before I go work out the bugs in the CAN2.0 area. There doesn't seem to be nothing wrong with your code
Posting Permissions
Reply With Quote