• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 525 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Error Code generated during insmod of tcan module

Akshay Naik
Prodigy 80 points
Part Number: TCAN4550

Hi, 

We are facing an issue when inserting the kernel module for CAN FD. Specifically, we found that our vehicle CAN FD network locks up the moment we issue insmod /iwtest/kernel-module/tcan4x5x.ko on the TCU. There are at least 4 other nodes on this CAN FD network, and we noticed typical CAN FD traffic just prior to issuing this insmod command. This is also well before Ip link is called to set up can2, so not sure how inserting this kernel module would cause issues. My understanding was that this should just insert the CAN FD module and set up SPI communications to but, but can you explain how inserting this module may affect the CAN_FD_H and CAN_FD_L end of the transceiver?

  • 0
    TI__Genius 15345 points

    Hi Akshay,

    We believe this is an issue with the driver and how it is written. The Linux probe function is calling an Init function that puts the device into normal mode. But the device should stay in standby mode until a baud rate is configured into the device. Since the device has not been configured with a baud rate it most likely using the power on defaults and therefore it is throwing a bunch of errors when you try to communicate over CAN.

    We are going to check with a 3rd party that is writing driver updates for us to see if this can be fixed.

    Best,

    Chris

  • 0 in reply to Chris Ayoub
    Prodigy 80 points

    Hi Chris,

    Thanks for the update.

    This is a blocker for us. Can you please provide the updated driver to solve this issue as soon as possible.

    Is there any work around for this so that we can continue with our work?

    Regards,

    Akshay

  • 0 in reply to Akshay Naik
    TI__Genius 15345 points

    Akshay,

    I will let you know once we have the updated driver. Unfortunately I don't think there is a good solution here. The issue is the probe function in the driver. If you could skip that function or configure the device baud settings then that could work.

    Like I said this is developed by a company that isn't TI. We are working with them to fix their driver.

    In the meantime we do have written code that works on a microcontroller like the MSP430. Would something like that work for your initial debugging?

    Best,

    Chris

  • 0 in reply to Chris Ayoub
    Prodigy 80 points

    Hi Chris,

    I'm briefing you the scenario which we are testing. Please let us know if there is any mistake in what we are doing.

    We are testing TCAN4550 and we noticed that error frames get inserted the moment insmod is called on the TCU to insert the tcan4x5x.ko module. This is when the first ER type message is seen. Most of the CAN traffic stops after this because many CAN nodes go into an error handling state due to the errors seen on the CAN bus.

    Snapshot of the test setup has been uploaded

    :

    Below is our test procedure:

    * Sending the data from PCAN continuously to the Non Rugged TCU. Once tcan module is inserted during data transmission in the rugged TCU then we are observing that the error frames are getting generated and it is observed in the PCAN tool.

    1) Non Working Condition:

    * Sending the data frames from PCAN tool which has BRS bit enabled. Then the error frames are getting generated.

    2) Working Condition:
    * Sending the data from PCAN tool in which BRS bit is disabled. Then there is no issue observed.

    Below are few of the snapshots which might help you in checking the issue.

    In the test setup I have oscilloscope probes connected as follows:

    Channel 1 Measuring Lead: FD_CAN_H

    Channel 1 Grounding Lead: USB_GND

    Channel 2 Measuring Lead: FD_CAN_L

    Channel 2 Grounding Lead: USB_GND

    1) Load the kernel module via insmod.

    2) Click on the 0x555 transmit message box on PCAN viewer and hit SPACE BAR on your keyboard to manually transmit.

    3) Oscilloscope should capture multiple payloads as seen below. PCAN trace log should also capture errors. Below are the snapshots for the same:

    4) In the Oscilloscope screenshot you can see two failed transmit bursts and then a successful transmit.

    5) Here’s a screenshot of the first failed transmit.

    6) Snaphot for the second failed transmit.

    7) Snapshot for the successful transmit is given below.

    8) Analyzing when the transmit frame gets stepped on above, it looks like it happens right after the BRS bit is sent out by the PCAN adapter. I suspect that tcan4x5x.ko driver sets the TCUs tcan4550 chip in a state that does not play well with BRS bits until we call ip link in a later step.

    Please check on this and let us know whether there is a driver change required or whether we are missing out anything in the test setup.

    Also could you please share us the driver for microcontroller like the MSP430 as mentioned in the earlier chat so that we can check on that?

    When can we expect the driver fix from the 3rd party? 

    Regards,

    Akshay Naik

  • 0 in reply to Akshay Naik
    TI__Mastermind 33400 points

    Hi Akshay,

    I've provided the same answer to your questions in your other thread, but for the benefit of this thread, I will add them here too.

    All notes on the bus should have the same settings and features enabled.  If a CAN FD frame is transmitted on the bus, ALL nodes must have FD enabled, otherwise the node that does not have FD enabled will throw and Error Frame on the message. 

    Likewise, if the FD message is transmitted with a faster Data rate, ALL nodes must have the BRSE, or equivalent Bit Rate Switch setting enabled and must have the same Data Bit Timing settings.  Otherwise, the node that does not have the BRSE enabled or has different Data Bit Timing settings will throw an error frame on the message. 

    Because error frames are generated when you have nodes trying to communicate with different configurations shows the system is working as intended during this test based on the CAN FD protocol and standards.

    This is a device support forum and I am not sure exactly when the driver transitions the TCAN4550 device from Standby Mode to Normal Mode.  However, the TCAN4550 always powers up into Standby Mode.  It will only transition to Normal Mode from Standby Mode when the processor sets the MODE_SEL bits in the Modes of Operation and Pin Configuration Register 0x0800[7:6] to Normal Mode (2'b10).

    The BRS error is due to not all nodes on the CAN bus having the same settings that allow them to handle CAN FD messages with a faster data rate than the arbitration rate.

    The error frames are generated at the device level because the CAN FD protocol is being violated with incompatible settings for the different nodes on the bus.

    TI is engaged with a 3rd party to improve the TCAN4x5x Linux Driver by optimizing the SPI communication to remove idle time and improve the data bandwidth.  This driver update is not intended to address the issues you are facing.

    To resolve error frames getting generated when the TCAN4550 is transitioned to Normal Mode, you must first ensure that both the BRSE and FDOE bits in the Control register 0x1018[9:8] are set to "1" and also ensure that both the Nominal (arbitration) Bit Timings (register 0x101C)_and Data Bit Timings (register 0x100C) are configured to the same values as the other nodes on the bus as I've just explained.  If these settings do not match the other nodes on the bus, error frames will get generated.

    Note, that devices configured to support CAN FD messages with Bit Rate Switching will not throw error frames on classical CAN messages (non-FD messages) and also on CAN FD messages that do not use Bit Rate Switching because the message header specifically instructs the node on whether the message is non-FD, FD, and or has BRS enabled. 

    Therefore, for FD operation you should enable the BRSE and FDOE bits and set the NBTP and DBTP timing values for the appropriate data rates used on the bus.  This should prevent your errors when switching the device to Normal mode.

    Regards,

    Jonathan