• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 582 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.

Original question:

TCAN4550: TCAN4550: Port to kernel version 4.9

TCAN4550: TCAN4550 Driver for Linux 2.6

Lenna Yan
Intellectual 1960 points
Part Number: TCAN4550

Hi Expert,

Customer is currently using Linux 2.6. They made some change based on the linux 5.8 related driver code in the processor. During the debug process, it can receive the data successfully when setting TCAN4550 in loopback mode. While when setting it to normal mode, the received results are all 0. I see there is another post on E2E that said the driver was introduced in Kernel version 5.4 and backporting to earlier versions would need to be done manually. Could you tell what steps the customer should do to make it work on Linux 2.6? The customer's code is as the attachment. Could you help check what may cause the issue?

tcan4550.rar

  • 0
    TI__Mastermind 33190 points

    Hello Lenna,

    I will look into this issue and I have a few questions that will help me narrow in on the solution.  Also, this is not a Linux support forum and I am not in a position where I can be of much help on your last question regarding the steps needed to backport the driver to older versions of Linux.  The TCAN4550 driver has been adopted and integrated into the Linux Kernel and Linux specific issues with the driver should be addressed in a Linux Support Forum.  I am glad to help you with any device specific issues and getting the register settings configured properly and or solving any schematic and hardware issues that may be preventing the operation of the device.

    Since you state the device was capable of successfully receiving data in Loopback mode, I would suspect it should be able to receive data from an external source.  However, there are two different loopback modes (External and Internal).  Which version did they use during their development? 

    Can you please provide some additional information regarding the test setup and what other devices are connected to the board with the TCAN4550 and where the CAN bus termination structures are placed?  Can you provide a schematic or block diagram?

    Is there another device sending CAN messages to the TCAN4550 board through a CANH and CANL pins, or are they trying to use the same TCAN4550 device to both transmit and receive data?

    Loopback mode causes the device to ignore acknowledge errors and assumes there there will not be an acknowledgement from another node and the purpose of the loopback mode is to self-test the TCAN4550. 

    When the device is operated in Normal Mode, there must be a second node connected to the CAN bus that will acknowledge any messages sent by the TCAN4550 and there must be 120ohm termination resistors places between the CANH and CANL pins at each end of the wires connected between nodes per the CAN standard.  If these termination structures are not in the system the communication will not be successful.  The TCAN4550 will also need to acknowledge the messages sent by the other node, otherwise it will not store the messages and if they are not acknowledged because they are assumed to contain errors.

    Can you provide any scope plots of the CAN messages sent from another node to the TCAN4550 node that shows the message and the acknowledgement by the TCAN4550? 

    The previous questions will help determine if this is a hardware or test setup issue, or a firmware issue.  Since it worked in loopback mode, I am thinking a hardware issue is somewhat likely.  But while I am waiting for answers to the previous questions, I will also review the code you have provided and try to find some obvious error or register setting that needs to be adjusted.  This will take a little time so I will have to follow up on that in a future post.

    Regards,

    Jonathan