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.

TCAN4550EVM: How to configure the controller mode?

Part Number: TCAN4550EVM
Other Parts Discussed in Thread: TCAN4550, MSP430FR6989, , TEST, BOOSTXL-CANFD-LIN

Hi team

I want to configure the TCAN4550 into controller mode, send CAN frame via SPI interface and then check the output on GPO2. Can you tell me how to configure the HW connection and SW configuration to achieve this?

I have one MSP430FR6989 Launchboard and TCAN4550EVM, the reason I choose MSP430FR6989 as the MCU board is that I found this device number in the TCAN4550 drive code.

 

I have done some work:

For HW connection

TCAN4550EVM

  1. TCAN4550EVM is powered by a DC source through J8(->VSUP) on TCAN4550EVM.
  2. VIO SELECT(S1) is chosen to be in 3.3V output.

MSP430FR6989 LaunchBoard

  1. P1.4 -> SPI CLK
  2. P1.6 -> MOSI
  3. P1.7 -> MISO
  4. P2.5 -> SPI CS

For SW configuration

  1. TCAN455x Driver Library Demo is the reference code, which is from the TCAN4550 product folder page.
  2. I add TCAN4x5x_Device_EnableTestMode(TCAN4x5x_DEVICE_TEST_MODE_CONTROLLER)  after the Init_CAN() to try to make TCAN4550 into controller mode

    ... ... ... ...

    /*********************************************
    * Everything at this point is for TCAN4550 *
    *********************************************/
    Init_CAN(); // Run the main MCAN configuration sequence. The bulk of the configuration is in this!

    TCAN4x5x_Device_EnableTestMode(TCAN4x5x_DEVICE_TEST_MODE_CONTROLLER);

    /* Define the CAN message we want to send*/
    TCAN4x5x_MCAN_TX_Header header = {0};

    ... ... ... ...

  3. To detect the output on GPO2 using the following code.

    TCAN4x5x_MCAN_TransmitBufferContents(1); // Request that TX Buffer 1 be transmitted

    TCAN4x5x_MCAN_TransmitBufferContents(0); // Now we can send the TX FIFO element 0 data that we had queued up earlier but didn't send.

Can you tell me what else I still need to do to accomplish my goal?

Thank you.

Shawn Wang

shawn-wang@ti.com

  • Hi Shawn,

    From your description you appear to be on the right path to getting this setup.

    Powering the TCAN4550 EVM from the J8 VSUP pin is correct.  What voltage are you using for VSUP?

    From the photo you provided of your board setup, I noticed that the GPO2 LED is connected to GPO2 in addition to the Header pin that you will be trying to monitor the TXD data.  The GPO2 LED dip switch on S4 should be de-selected (toggled towards the outside edge of the board) to improve signal integrity on the GPO2 data (TXD_INT_CAN). The LED is useful when GPO2 is used as an interrupt for visual indication of the pin state but the LED is not intended to be used when the pin is used as a data pin in a Test Mode. This is the purpose of the Dip Switch which will allow the LED to be easily disconnected from the net.

    Using the TCAN4x5x_Device_EnableTestMode(TCAN4x5x_DEVICE_TEST_MODE_CONTROLLER); function to place the TCAN4550 into test mode looks correct.  However, the Controller Test Mode will remove the integrated CAN transceiver from the system, but the controller will still be expecting normal CAN behavior such as the TXD looped back to RXD pin that occurs inside the CAN transceiver.  If you don't connect an external transceiver to the TCAN4550 operating in Controller mode, loop the TXD data back onto the RXD pin, and/or make any additional configuration changes, I think the TCAN4550 will consider this an error condition and could disable itself or prevent you from observing the data.

    Also, without an additional CAN node (transceiver and controller) such as a second TCAN4550 EVM or a CAN Analyzer test equipment that can "acknowledge" the CAN packet you are trying to send, then the TCAN4550 controller will also consider this an error and an unsuccessful transmission which could result in a "bus off" condition and prevent you from monitoring your CAN packet on the GPO2 pin.

    I have not tried to setup a test configuration like you are trying to do, and I will need to spend a little time to work through a more detailed configuration to offer you regarding which additional register bits need to be set, and if any additional hardware connections will need to be made.  I will work on this and post again tomorrow or as soon as I have a complete solution for you.

    Regards,

    Jonathan

  • Hi Jonathan

    Thanks for your prompt reply!

    1. VSUP is 9V, this should be ok for the TCAN4550EVM supply.

    2. For the external CAN transceiver

    I can't find a header connected to GPIO1 on TCAN4550EVM, maybe it is not convenient to connect an external CAN transceiver with TCAN4550EVM through GPO2 and GPIO1. How about using MSP430FR6989Launch board + BOOSTXL-CANFD-LIN(configured as the controller mode) + TCAN1042EVM to set a CAN node?

    3. For an additional CAN node

    TCAN4550EVM is a good choice as you said. Do I need to connect an MCU board with TCAN4550EVM to achieve an additional CAN node?

    I want to prepare some hardware in advance and look forward to your input and complete solution.

    Thank you!

    -------------------------------------------------------------------------

    In addition, I did tests to detect the CANH or CANL of TCAN4550EVM in normal mode, the hardware connection is as the picture in my last post. The code is as follows.

    /*********************************************
    * Everything at this point is for TCAN4550 *
    *********************************************/
    Init_CAN(); // Run the main MCAN configuration sequence. The bulk of the configuration is in this!

    /* Define the CAN message we want to send*/
    TCAN4x5x_MCAN_TX_Header header = {0}; 
    uint8_t data[4] = {0x55, 0x66, 0x77, 0x88}; 
    header.DLC = MCAN_DLC_4B; 


    header.ID = 0x144; // Set the ID
    header.FDF = 1; // CAN FD frame enabled
    header.BRS = 1; // Bit rate switch enabled
    header.EFC = 0;
    header.MM = 0;
    header.RTR = 0;
    header.XTD = 0; // We are not using an extended ID in this example
    header.ESI = 0; // Error state indicator


    TCAN4x5x_MCAN_WriteTXBuffer(0, &header, data); 

    /* Let's make a different CAN message */
    data[0] = 0x11;
    data[1] = 0x11;
    data[2] = 0x11;
    data[3] = 0x11; // Define the data payload

    header.DLC = MCAN_DLC_4B; 
    header.ID = 0x123; // Set the ID
    header.FDF = 1; // CAN FD frame enabled
    header.BRS = 0; // Bit rate switch enabled
    header.EFC = 0;
    header.MM = 0;
    header.RTR = 0;
    header.XTD = 0; // We are not using an extended ID in this example
    header.ESI = 0; // Error state indicator

    TCAN4x5x_MCAN_WriteTXBuffer(1, &header, data); // This line writes the data and header to TX FIFO 1
    TCAN4x5x_MCAN_TransmitBufferContents(1); // Request that TX Buffer 1 be transmitted

    TCAN4x5x_MCAN_TransmitBufferContents(0); // Now we can send the TX FIFO element 0 data that we had queued up earlier but didn't send.

    2 questions I have:

    1) Once this statement is executed TCAN4x5x_MCAN_TransmitBufferContents(1); // Request that TX Buffer 1 be transmitted, CAN frame can be detected on CANH and CANL continuously at a certain time interval. And the execution of the next statement, statement TCAN4x5x_MCAN_TransmitBufferContents(0),  will have no effect on the output.

    Is this the expected behavior in the condition without an additional CAN node?

    2) The CAN frame detected should be the output of the TX buffer 1, detailed bits shown here:

    a. The code set the ESI equals to 0, but the detect value is 1. Does this mean an error was detected?

    b. What does "0011" with the horizontal line mean?

  • Hi Shawn,

    It looks like you generally have a setup working.  You will need a transceiver (such as the TCAN1042 EVM) connected to the GPIO1 and GPO2 pins or loop back the GPIO1 and GPO2 pins to each other to prevent the controller seeing an error while in controller test mode.  Due to the way CAN arbitration works, when it tries to send a packet, it monitors the RXD pin to make sure it matches the value on the TXD pin.  If these don't match, the controller will stop transmitting thinking it lost arbitration.  I actually think this is your primary issue when you tried to use the controller test mode.  When you switched to the normal mode, the internal transceiver is looping the TXD signal back to the RXD signal allowing you to see the waveforms on the CANH and CANL pins.  However, you don't have a second node to acknowledge the message so it is constantly trying to resend the same message since it has been unsuccessful at sending it.

    Thanks for the information on the VSUP rail.  Using a VSUP of 9V is good.  There is a polarity protection diode that will drop the voltage seen by the pin by a diode drop, but you have plenty of margin to keep the voltage at the TCAN4550 pin greater than 6V, so there is no issue here.  I was mainly curious to make sure we didn't have any form of voltage issues in your setup.

    You can use either the TCAN4550 EVM or the BOOSTXL-CANFD-LIN boards for this application.  I designed the EVM as a generic board that could be used with any MCU board using jumper wires.  I then designed the BoosterPack to make it easier to mate and evaluate the TCAN4550 with a TI MCU LaunchPad.  There are a couple of minor differences between the boards such as the BoosterPack has an additional LIN transceiver, but from the TCAN4550 perspective, they are equivalent.

    Both the GPIO1 and GPO2 pins are on connected to the bottom Digital IO header of the EVM.  I have highlighted them in the below image.  The EVM was designed to support future devices of the TCAN4x5x family that may support a wider VIO rage (2.5V and 1.8V) as well as a potential Output clock that could be supplied to the MCU based on the crystal used for the TCAN4550.  This Clock Out feature is not yet available, but this is the reason for the extra SMA and silkscreen label on the header pin.  I apologize if it has caused any confusion.

    I would suggest you connect a second TCAN4550 and MCU combination to your current setup in order to have a fully complete and functional CAN FD bus that can acknowledge messages and both transmit and receive packets to each other.  This will help fully evaluate your setup and would be a much better solution than trying to use a single board with an external transceiver due to the acknowledge errors you will be receiving.  Generally speaking, 2 complete nodes are required for a CAN bus to work properly.

    Regarding the ESI bit, this is most likely a result of the error created by an unsuccessful transmission of the message due to the lack of an acknowledging node.  Adding a second node should clear this up.

    Regarding the bits immediately after the 4 DLC bits, I believe you have missed an additional "0" and there should really be 5 "0" bits between the "1" bits.  The first "1" bit is a "Stuff-Bit" that is inserted by the controller automatically when it detects 5 or more consecutive bits of the same value.  When it detects this, it will insert a bit of opposite value into the field that the receiving nodes will automatically discard.  Since the DLC field is "0100", followed by the first data field of "0001", there is a string of 5 consecutive "0" bits causing the stuff bit to be inserted before the "1" bit that is part of the original Data byte.  I also believe that the CRC bits following the data bytes just happen to appear as another "0001" data byte giving the illusion of a mystery byte of data "0011".

    Regards,

    Jonathan

  • Hi Jonathan

    Thanks for your prompt reply. Your reply answers all my doubts, Thank you!

    So my understanding is that a complete evaluation system can refer to the combination shown as follows. (I don't connect all wires and it is just a schematic diagram.)

    Can I just connect these two CAN nodes through 2 Dupont Lines?  the yellow wire and the blue wire connected between TCAN1042EVM and TCAN4550EVM.

    Later, depending on customer feedback, I will consider whether to use the combination shown above for a complete evaluation,

    Thanks for your support.

  • Hi Shawn,

    I am glad I was able to help you!

    Yes, what you have shown in your picture should work.  You only need to provide a CANH and CANL connection as you have shown between the two nodes and then make all the other connections between the TCAN4550 EVM and the MCU LaunchPad as we have already discussed.  Outside of configuring the MCU with the TCAN1042 for Controller Mode, the bit timing and other settings between the two nodes can be the same.

    Regards,

    Jonathan

  • Jonathan

    Thanks for your help.

    "Outside of configuring the MCU with the TCAN1042 for Controller Mode, the bit timing and other settings between the two nodes can be the same."

    Do you mean "Outside of configuring the MCU with the TCAN4550 for Controller Mode,..."

  • Hi Shawn,

    I am sorry for any confusion.  I will try to clarify.

    In your setup, you have two "nodes" where each node consists of an MCU and TCAN4550.  One of those nodes uses a BoosterPack, and one of them uses the generic EVM for the TCAN4550.  If you used the integrated CAN FD Transceiver of the TCAN4550, you could configure both of these nodes with the same settings, or even the exact same firmware and they would be able to communicate with each other despite being implemented on different types of boards.  My point is that the TCAN4550 bit timing and other configuration settings are the same.

    However, you are trying to bypass the internal transceiver of the TCAN4550 on one of those nodes by using it in Controller Mode and adding a TCAN1042 transceiver.  In this node, you can't use the exact same TCAN4550 register configuration as the node where you are using the internal transceiver.  You must modify the code and register settings to place it into controller mode.  However, my point was that outside of making this simple controller mode modification, all the other bit timing, clock, and other register settings of the TCAN4550 can be the same as those you are using in the node that uses the TCAN4550 internal transceiver.

    The larger point is that using bypassing the TCAN4550 transceiver in order to use an external transceiver such as the TCAN1042, should be a very easy code modification from an application that uses the TCAN4550 in normal mode with the internal transceiver.  It was a simple comment that you shouldn't need to worry about needing to make major code modifications in order to use the TCAN4550 in controller mode.

    I hope this clears up my previous post, but I believe you have a complete and correct understanding of how to get your system configured.

    Regards,

    Jonathan

  • Hi Jonathan

    I still have a question about the speed of CAN FD.

    I know that set BRS bits to recessive (1) means that the remaining part of the data frame is sent at a higher bit rate (up to 5 Mbit/s). 

    Hence my question is when using a CAN FD controller, can I set the CAN FD speed to a certain value by using commands or the speed is just only controlled by other factors (like working temperature and wire length) and cannot be set artificially? Thank you!

    Happy Chinese new year! 

  • Hi Shawn,

    Happy Chinese New Year to you too!  And I am sorry for the late reply as I lost track of this thread and just saw your last post.

    I think the answer to your question is No, there isn't a "command" to set the speed, but also No, other factors such as temperature and wire length do not cause the speed to change.  The speed is set as a result of configuring the Bit Timing parameters such as DTSEG1, DTSEG2, DBRP, DSJW, etc. (register 0x100C).

    When you configure the TCAN4550 with the Nominal and Data Bit timing, the controller will use these settings for all messages.  All devices on the Bus should be configured for the same speed with the same timing parameters in order to ensure proper communication and prevent nodes from issuing errors.  The controller simply allocates the specified amount of Time Quanta for each portion of the bit time.  In this sense, you must have previously determined the amount of Time Quanta required for each bit based on the Input Clock frequency (usually 20Mhz or 40Mhz).  The controller has no method of determining a specific Bit Rate such as 500kbps, 2Mbps, or 5Mbps based on predetermined settings.  If you want to change the speed, you need to simply change the allocation of the various settings which will result in bits that are either faster or shorter.

    But in that sense, the MCU could change the data rate at any time by having the MCU Write to these registers which effectively could be considered a "command."  Bu there is not a simple set of commands or a register with predetermined settings.

    I hope this answers your question and again I apologize for the delay in my response.

    Regards,

    Jonathan