TCAN4550-Q1: Receive and send problems.

Hi  Eric:
Thank you for your reply.

I use your Linux driver code.

m_can.c
static void m_can_chip_config(struct net_device *dev) {
...

/* Disable Auto Retransmission (all versions) */
+++ cdev->can.ctrlmode = cdev->can.ctrlmode | CAN_CTRLMODE_ONE_SHOT;
if (cdev->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)
cccr |= CCCR_DAR;
...
}
As for the above modification, I checked the register to confirm that the setting was successful, but I used the can analyzer to observe that no data was sent.

Arvin,

It sounds like another error may be occurring when sending a CAN frame. Can you read register 0x1040 to see the last transmit error code?

Regards,

Eric Hackett

root@linux-perf:~# ./cansend can0 -i 12 0x11 0x22 0x33
interface = can0, family = 29, type = 3, proto = 1
<4>[ 59.399147] [tcan]m_can_start_xmit[1814]:start.
<6>[ 59.399193] tcan4x5x spi6.0 can0: TX packets(data_len = 16):
<4>[ 59.399205] 0c00 0000 0300 0000
<4>[ 59.399240] 1122 3300 0000 0000
<4>[ 59.399272]
<4>[ 59.399320] [tcan]m_can_start_xmit[1841]:end.
<4>[ 59.399369] [tcan]m_can_tx_handler[1666]:start.
<6>[ 59.399387] tcan4x5x spi6.0 can0: TX packets(data_len = 16):
<4>[ 59.399395] 0c00 0000 0300 0000
<4>[ 59.399427] 1122 3300 0000 0000
<4>[ 59.399459]
<4>[ 59.399471] [tcan]m_can_tx_handler[1673]:cf->can_id=0x0000000c.
<4>[ 59.399483] [tcan]m_can_tx_handler[1681]:cf->can_id=0x0000000c.
<4>[ 59.401471] [tcan]m_can_tx_handler[1759]:fifo_header.id=0x00300000, fifo_header.dlc=0x00830000.
<4>[ 59.401842] [tcan]m_can_tx_handler[1766]:cf->data[0]=17.
<4>[ 59.401858] [tcan]m_can_tx_handler[1767]:cf->data[1]=34.
<4>[ 59.401870] [tcan]m_can_tx_handler[1768]:cf->data[2]=51.
<4>[ 59.401881] [tcan]m_can_tx_handler[1769]:cf->data[3]=0.
<4>[ 59.402752] [tcan]m_can_tx_handler[1791]:end.

root@linux-perf:~#
root@linux-perf:~# echo 1040 > /sys/kernel/debug/tcan/tcan4x5x_reg
root@linux-perf:~# cat /sys/kernel/debug/tcan/tcan4x5x_reg
0x00010008
root@linux-perf:~#

the value of register 0x1040 is 0x00010008.

Arvin,

It looks like there are some transmit errors occurring based on the reading of 0x1040, can you also get the value of register 0x1044? This will give us the type of error that's occurring.

Regards,

Eric Hackett 

Eric Hackett said:

0x1044

0x1044   ->      0x0000070b

Arvin,

This shows an ACK error is occurring. As Eric Schott stated earlier, an Ack Error is occurring because there is no other CAN node acknowledging the message coming from the TCAN4550-Q1. When you disable DAR, is the analyzer not seeing anything at all? Or is it simply throwing out the message because there is no acknowledge? Is there a way to set the analyzer to send an ACK itself, or is it not capable of transmitting messages?

Regards,

Eric Hackett 

HI Eric:
cccr |= CCCR_DAR;

Normally, a frame of data should be sent out.  right?

but i don't see any information on the can logic analyzer in this mode.

Using an oscilloscope also didn't find any waveforms on canl and canh.

The device is only connected to the can logic analyzer, I don't know if a logic analyzer can be considered a node?

Hi Arvin,

A Scope, Logic Analyzer, or most other standard test equipment is not considered a node if they do not contain a physical CAN transceiver and CAN controller that will connect to the CANH and CANL lines to receive and acknowledge the CAN messages.  There are a variety of CAN Bus Analyzer tools that are typically USB based CAN tools with internal CAN Controllers and MCUs that will pass the CAN data to the computer running software.  A web search for CAN Bus Analyzer will point you to a variety of options.

Another alternative is to simply place a second TCAN4550 based board on the bus to receive the data and then you can use traditional scopes and logic analyzers to monitor the data as it passes between the boards.

If you don't have a second board, the best option is to configure the board for External Loop Back Mode by setting the TEST.LBCK bit to '1' and the CCCR.MON bit to '0'.  In this mode the device will broadcast the CAN message to the bus so that you can view it with a Scope or Logic Analyzer and loop the message data back to the RX input allowing you to see the transmitted message in the RX FIFO or dedicated Buffer.  However, this is a test mode and therefore the device will ignore the Acknowledge (ACK) errors because there isn't another device on the bus acknowledging the message.

The following image is taken from the Bosch M_CAN User's Guide and shows how the Internal and External Loop Back Test Modes are configured.  You can find the full guide at this (Link).

Setting the Disable Automatic Transmission (DAR) bit to '1' will simply prevent the device from trying to send the message more than once in the case there was no acknowledgement of the first transmission attempt. But when you are in External Loop Back mode, the DAR bit should not need to be set.  If you do not have the TEST.LBCK bit set to '1' and you do not see activity on a scope or logic analyzer, then you likely have a trigger, horizontal scale, and or vertical scale issue. The CAN message will only be transmit a single time and it is easy to miss it if the equipment is not setup properly.

Regards,

Jonathan