Original question:
TCAN4550-Q1: After 1 to 3 hours of normal use, data cannot be sent
Tool/software:
The problem reappears regularly, and I read all registers when the problem occurs:
Hello!
1、 The "CAN0" mentioned above corresponds to the "CAN1" interface in the schematic diagram, and the terminal resistor on "CAN1" is connected to another distant transceiver position, as shown below:
2、When our device fails to send, it can receive data normally, which should have nothing to do with the crystal oscillator and power supply of the TCAN4550 chip, otherwise it can not receive data normally
Hello Jonathan Nerger,
1、Now the CAN bus waveform in the case of positive difference communication is measured, but it cannot be measured temporarily in the case of abnormal communication.
There are a total of nine devices on the bus, and only my device CAN0 has the following waveform when sending data：
When the following eight loads are also powered on, some devices also start to communicate when the waveform is as follows:
2、have a 0.1uF (100nF) capacitor between the two 60.4 ohm termination resistors
When there is a problem, the 120Ω resistance directly used at the beginning is as follows, without the 60.4Ω resistance and 100nF capacitor, and the state you see in the above figure is changed later, so the abnormal state that the equipment can only receive and cannot send will occur about 2 hours after use in both ways.
3、Is there only the one set of termination resistors on your CAN bus, or are there two sets of termination resistors?
Yes, there is a terminal resistor on the other end of my bus, and the usage of my two TCAN4550 devices is as follows:
Hello Jonathan Nerger,
There is also a 120Ω resistor on the board of Device 1, as you can see in the schematic diagram
I'm sorry, I misunderstood the termination locations. I stand corrected.
The scope plots still show that the dominant and recessive voltage levels should be sufficient to to sample the bits correctly. With limited information on the register log file, and no scope plots of the transmitted frames that generated the errors, I'm not sure what is causing the errors.
Looking back at the previous information, I see the sample point for the bits is set to 87.5%. I believe the Linux driver calculates and assigns the number of time quanta (or high speed clock cycles) to be used to create a bit period that matches the desired rate. It also calculates the sample point by assigning the number of time quanta to be used before and after the sample point. Sampling the bit near the end of the bit may not work for all applications and you may get better results by adjusting the sample location a bit earlier. You might try to move the sample point and see if there are any improvements. This can be done by adjusting the ratio of the time quanta allocated in the NTSEG1 and NTSEG2 fields of the Nominal Bit Timing and Prescaler Register (0x101C).
Regards,
Jonathan
We tried to change the sampling point of all devices on the bus to 0.80, but the problem still occurred.
Hello Hangziang,
Do you mean that we need to record these two registers from the moment the CAN device starts working? How long is the recording interval?
What I mean is that in order to determine what is causing the errors in the CAN messages, we need to try and capture some of real-time error counter and status register values that will report what the specific type of error was. Register 0x1040 is the Error Counter Register and will contain the Transmit and Receive Error Counter values (TEC and REC). If either of these counters exceeds 255, the device will enter a Bus Off (BO) condition and the device will disconnect itself from CAN bus communication.
Register 0x1044 is the Protocol Status Register and it will contain error codes for the type of CAN bus error that was detected on the last message. Therefore, if we can capture the value of this register for the messages that had errors, we can determine what type of errors are occurring on your bus and then hopefully try to figure out how to prevent them.
Here are the two register values I grabbed after the problem occurred
You read back 0x104E instead of 0x1044 which won't return the correct value. Also, 0x1040 = 0x00000000 shows both the TEC and REC error counters are at 0, so this doesn't provide any helpful information.
When the problem occurs, cansend cannot successfully send data (candump does not see data packets, ip -d -s link show can0 does not see an increase in sent data packets)
My expertise is with the TCAN4550 at the device level and I am not a Linux expert. If this is an issue with the TCAN4550 and it's configuration we will need to monitor and record the information the device is providing us through the registers before, during, and after the issue occurs. If possible please try to monitor the following register values into some form of log file so that we can try to determine the root cause of the errors.
0x000C
0x0800
0x0820
0x0824
0x1018
0x1040
0x1044
0x1050
0x10A4 (If using RX FIFO 0)
0x10B4 (If using RX FIFO 1)
0x10C4
0x10CC
0x10D8
If the device stops sending due to accumulating too many errors and entering a Bus Off condition, then the processor will need to re-initialize the CAN communication by clearing the INIT bit in the Control register (0x1018[0] = 0), or issuing a hardware or software reset and fully re-configuring all of the device registers just like an initial power up configuration.
Regards,
Jonathan
I read the 0x1040 and 0x1044 registers every 100 ms and log when a change occurs, and get this
The format is [hours, minutes, seconds, milliseconds] (0x1040,0x0144 register value after change)
The problem occurred at about 14:51:43 p.m.
Scenario: Device A sends a heartbeat packet to device B on the CAN bus via tcan4550. The process continues until device B discovers that it has lost the heartbeat packet from device A. At this point, we find that device A can still receive data packets from the bus normally via tcan4550, but it cannot send a successful data packet.
Monitoring more registers at too high a frequency will affect the normal interaction process of tcan4550, so other registers are not monitored for the time being.
Hello, I have re-recorded the registers, and now the format is [hour, minute, second, millisecond] (the changed register values are "0x1040" "0x1044" "0x10c4" "0x10cc" "0x10d8"), and the problem occurred around 14:53 in the afternoon.
After repeated verification, we confirmed the problem: there is a vulnerability in the sending logic of the kernel driver.
Since there is only one sending fifo, in the sending thread, the sending register M_CAN_TXBAR is enabled first, and then the sending fifo is determined to be full. If the fifo is full, the can software queue is closed. After judging that the fifo is full, an interrupt may interrupt this process, causing the logic judgment to fail.
