This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCAN4550-Q1: The data after 8th byte is not transmitted

Part Number: TCAN4550-Q1
Other Parts Discussed in Thread: TCAN4550

Hello Expert,

I use to TCAN4550 to transmit a CAN FD frame with 16 bytes of data. The data length is defined as 16 bytes. The baudrate for data is 2mbps, and 500kbps for header. This is code used for header of the frame.

uint8_t data[16] = {0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0x11, 0x22, 0x33, 0x44, 0x5A, 0x5B, 0x5c, 0x5d}; 
header.DLC = MCAN_DLC_16B; 
header.ID = 0x145; 
header.FDF = 1; 
header.BRS = 1; 
header.EFC = 0;
header.MM = 1;
header.RTR = 0;
header.XTD = 0; 
header.ESI = 0; 
retVal = MCAN_WriteTXFIFO(0, &header, data); 

AHB_WRITE_B_FL_32(M_CAN_TXBAR, 0x00000001); 

I transmitted 16 bytes data, but I only got 8 bytes. I am using CAN FD analyzer as 2nd node. Which section should I pay more attention to find the root causes? Thanks

  • QJ,

    We are looking into this and will get back to you early next week.

    Max
  • HI Max,

    Any suggestion?

    Regards,
    QJ
  • QJ,

    Sorry about the delay, is there any way you can get an image of the waveforms on an oscilloscope when you send the data? There might be an issue with the CAN analyzer being able to interpret the messages.

    Regards,
  • Hello Eric,

    Attached please find the waveform I captured from the scope. It is traditional CAN message rather than CAN-FD message. Thanks

    TCAN4550_Test1.docx

  • Hi Eric,

    I enabled the FD mode in CCCR register:
    /* Configure the MCAN core settings */
    TCAN45x0_CCCR_Config cccrConfig = {0}; // Remember to initialize to 0, or you'll get random garbage!
    cccrConfig.FDOE = 1; // CAN FD mode enable
    cccrConfig.BRSE = 1; // CAN FD Bit rate switch enable
    cccrConfig.DAR = 1; // Disable automatic transmission

    And TX Message RAM:
    uint8_t data[16] = {0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa}; // Define the data payload
    header.DLC = MCAN_DLC_16B;
    header.ID = 0x145; // Set the ID
    header.FDF = 1; // CAN FD frame enabled
    header.BRS = 1; // Bit rate switch enabled
    header.EFC = 0;
    header.MM = 1;
    header.RTR = 0;
    header.XTD = 0; // We are not using an extended ID in this example
    header.ESI = 0; // Error state indicator
    retVal = MCAN_WriteTXFIFO(0, &header, data);
  • The invalid ACK bit in my test waveform was caused by the termination on CAN bus. The TCAN4550 EVM has 120ohms termination, but the CAN FD analyzer doesn't. After I added another 120 ohms termination resistor to the CAN bus, the ACK bit is OK.

    Another question, how to enable the CAN FD to transfer 64 bytes of data with high baudrate?
  • QJ,

    The global FDF bit has to be enabled in the CCCR register, and the FDF bit in the TX header of the message also has to be set to allow for CAN FD communication. Your data payload for RX and TX also have to be configured for 64 byte data fields, I believe these are found in registers 0x10BC and 0x10C8.

    Have you been able to work through the rest of the issues you were seeing?

    Regards,
  • When I write header and data to TX buffer through SPI, is there any requirement for the delay between each transfer (8-bit byte). The CS keeps LOW for the whole transfer (header + data). What are the minimum delay and maximum delay allowed?
  • Thanks Eric,

    I enabled the FDF bit in CCCR and TX header, and the TBDS[2:0] bits of TXESC is 0x7 (64 bytes).

    If I use different baudrate for data, I saw the correct baudrate for both data (2mbps) and arbitration field (500kbps). The baudrate is switching at BRS bit field, and causes the BRS bit width be 1.5us (should be 2us for 500kbps), and the following ESI bit is 500ns (for 2mbps baudrate). The DLC is 0x1010 which means 16 bytes data, but only 8 bytes data are transmitted.

    The data transmitted are 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa

    I am not sure if the CRC is correct, will check. The CAN FD analyzer says there is stuff error in the frame.

  • The problem has been solved, Thanks Eric.