TCAN4550-Q1: loopback test

Hi Kailyn,

I believe the driver simply enables the internal loopback test mode of the TCAN4550 device, at least that is what it supposed to do.  There are a couple of different test and loopback modes the device will operate in that depend on how the combination of several bits are set.  Can you read back the following device registers so that we can verify how the device is configured and see if there is something that needs to be adjusted?

0x0800 (Modes of Operation and Pin Configuration)

0x1010 (Test Register)

0x1018 (Control Register)

The following registers will help me understand and check the RX configuration so see how the device is being configured to receive the messages.  There are two RX FIFOs as well as dedicated RX Buffers that could be used to store received messages, and therefore, there may be a problem with the driver placing messages in one location and checking for new messages in another.  Message filter elements can be created to direct messages to different locations, and while this is probably unlikely, it is worth checking.

0x10A0 (RX FIFO 0 Configuration)

0x10A4 (RX FIFO 0 Status)

0x10B0 (RX FIFO 1 Configuration)

0x10B4 (RX FIFO 1 Status)

0x10AC (RX Buffer Configuration)

0x10BC (RX Buffer/FIFO Element Size Configuration)

Also, it would be good to just read back the basic device interrupt and status registers so that I can see if there are any faults or status flags that could be set which would prevent the device from operating properly

0x0820 (Interrupts)

0x0824 (MCAN Interrupts)

Regards,

Jonathan

Arvin,

Thanks for the register values and also for the MRAM configuration which confirms the values I have decoded out of the registers in terms of the number and types of TX/RX FIFO and buffer elements.

I can't say that there are any problems with the MRAM configuration because this all depends on what you will need in your application.  The TCAN4550 device has 2KB of Message RAM (MRAM) memory that can be allocated to your application.  If you need more elements than what has been currently allocated, it does look like you should have available space to increase the number of elements allocated.

The TSW interrupt bit is not a concern and is only an indication that the timestamp counter has reached the maximum counter value and wrapped around to the beginning.  This counter is used as a way to add a timestamp to messages that may be valuable to the system.  For example, keeping track of the order of message reception, or transmission may be important because arbitration may cause the messages to be transmitted in a different order than they were loaded into the queue based on the message ID's priority status.  This TSW bit lets the MCU know that the counter has wrapped around and if this feature is used, it can keep track of this.  If the timestamp counter is not used, this is something that can be masked, ignored, or cleared without taking any additional action.  The counter is not very big, so it can wrap around quickly.  Some dividers can be configured to slow it down if needed.

After evaluating the register values, I can confirm your MRAM allocation, and I also see that the device is configured for Internal Loop Back Mode.  The TEST.LBCK bit (0x1010.4) is set that enables the TX data to loop back to the RX.  Also, the CCCR.MON bit (0x1018.5) is set which disconnects the TX data from reaching the CAN bus.  This is why you are unable to see the TX message with an external CAN analyzer when Loopback mode is enabled.  However, if you clear the CCCR.MON bit, this will configure the device for an External loop back mode which will allow the TX data to be output on the CAN bus as well as looped back to the RX input.  The external CAN bus data will not reach the RX input in this mode.  The following image is taken from the Bosch M_CAN User's Guide and is a good illustration of how the device is configured.  You can find the full guide at this (Link).

I also see that a new RX message has been received.  The RF0N bit of the MCAN Interrupts register (0x0824.0) is set to '1' indicating a "New RX FIFO 0 message."

The RX FIFO 0 Status register also indicates that the RX FIFO 0 Fill Level = 1, meaning one element in the FIFO contains a message that has not been acknowledged 0x10A4.6:0.  The RX FIFO 0 Put Index has also been increased to 1 (starts at 0) to indicate that the next message will be placed into the FIFO element 1 memory location.  The RX FIFO 0 Get Index (0x10A4.13:8) is set to 0, indicating that the next RX message that should be read is in the FIFO element 0 memory location.

Therefore, the TCAN4550 device appears to be configured and working properly.

Regards,

Jonathan

ok，thank you for you reply,  
I think I found the cause of the problem. I needed to add IRQF_TRIGGER_FALLING when applying for an interrupt. Now it works well. 

I don't understand why this is not added to the native driver?

do you have any idea in this question?  
TCAN4550-Q1: Receive and send problems. - Interface forum - Interface - TI E2E support forums

Forgive me for mentioning this problem in this case. Now it is early morning for me,we have a time difference of 13 hours. I hope to get a quick reply so that I can solve the problem efficiently. 

Hi Arvin,

I have added my comments to the other thread.

Regards,

Jonathan

thank you very much,  you can close this questions.

You're welcome.  Feel free to create a new post if you have additional questions.

Regards,

Jonathan