Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 45 of 45

Thread: FlexCAN_T4 - FlexCAN for Teensy 4

  1. #26
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    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!:
    was
    Code:
    //#define PRINT_DEBUG_STUFF
    is
    Code:
    #define PRINT_DEBUG_STUFF

  2. #27
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,402
    Very cool to see this developed and working tonton81!

    Quote Originally Posted by mjs513 View Post
    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!:
    was
    Code:
    //#define PRINT_DEBUG_STUFF
    is
    Code:
    #define PRINT_DEBUG_STUFF
    @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().

    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.

  3. #28
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    @defragster

    To be honest didn't think about inserting debug_tt to see what happens Was 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

  4. #29
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    @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)

  5. #30
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,402
    Quote Originally Posted by mjs513 View Post
    @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:
    ...
    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?

  6. #31
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    @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!

  7. #32
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,402
    Quote Originally Posted by mjs513 View Post
    @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.

  8. #33
    Adding
    Code:
    #define PRINT_DEBUG_STUFF
    Didn't work for me. It still doesn't get past FD.begin() but I'm using 1.47

  9. #34
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,402
    Quote Originally Posted by skpang View Post
    Adding
    Code:
    #define PRINT_DEBUG_STUFF
    Didn't work for me. It still doesn't get past FD.begin() but I'm using 1.47
    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

  10. #35
    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.

  11. #36
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    @skpang

    If you look through the lib there seem to be a couple of commands that may work - haven't tested though:
    Code:
        uint32_t getBaudRate() { return currentBitrate; }
        void setBaudRate(uint32_t baud = 1000000);
    That may help.

  12. #37
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,051
    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

  13. #38
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    @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.

  14. #39
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,402
    Quote Originally Posted by mjs513 View Post
    @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 ...

  15. #40
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,971
    @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.

  16. #41
    Senior Member
    Join Date
    Jun 2014
    Posts
    245
    Is FD only available on 30/31 or can it be MUXed to physical pins 0/1, 22/23?

  17. #42
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,463
    Only on the inconvenient bottom-side pins 30/31.

  18. #43
    Junior Member
    Join Date
    Sep 2019
    Posts
    2
    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?

    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);
      }
    }
    */
    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) |= 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);
      }
    }
    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!

    Tom

  19. #44
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,051
    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

  20. #45
    Junior Member
    Join Date
    Sep 2019
    Posts
    2
    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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •