• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 91 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.

TCAN337: TCAN337 - Application Error - CAN Failure - Acknowledge Error

Tirthraj Solanki
Prodigy 30 points
Part Number: TCAN337


Hello,

We are facing an intermittent CAN-FD issue in the field and would appreciate guidance from the community.

Our system has two devices on the bus (no other device on the bus) using a request–response architecture. The master sends a request every 30 ms and the slave responds. This setup is deployed in hundreds of units running continuously (24 hours). Out of these, around 3 to 5 units per day show acknowledgement errors, which we track through the CAN protocol error counters.

The behaviour is unusual:

• The issue appears randomly on any unit.
• No bus-off condition is ever reported.
• Despite no bus-off, communication between the two nodes temporarily stops.
• Communication recovers automatically after a few seconds without any intervention.

Initially, we suspected a physical wiring problem. We re-checked all connectors and even secured them with glue. The bus has 120-ohm termination at both ends. However, the issue still appears randomly.

Below are the system details:

Transceiver: TCAN337
Baudrate: 125 kbps
CAN bus length: ~100 cm
Termination: 120 ohms at both ends
FD-CAN Core Clock: 50 MHz
ClockDivider: 1
Bitrate Switching: Disabled
AutoRetransmission: Disabled
TransmitPause: Disabled
ProtocolException: Disabled

Nominal Bit Timing:
• Prescaler = 10
• SyncJumpWidth = 8
• TimeSeg1 = 31
• TimeSeg2 = 8

Data Bit Timing (BRS disabled, same as nominal):
• Prescaler = 10
• SyncJumpWidth = 8
• TimeSeg1 = 31
• TimeSeg2 = 8

Filters:
• StdFiltersNbr = 1
• ExtFiltersNbr = 0

Troubleshooting Steps Already Performed

  1. Physical wiring check
    • Verified connector seating and cable condition
    • Applied glue to prevent vibration-related disconnection
    • Confirmed correct 120-ohm termination at both ends

  2. Error counter monitoring
    • ACK errors observed in protocol error counters
    • No error-warning, error-passive, or bus-off states reported

  3. Timing verification
    • Checked nominal bit timing settings
    • Ensured both nodes use identical configurations
    • Bitrate switching is disabled on both sides

  4. Bus recovery logic
    • Bus-off recovery is implemented
    • Never triggered during these events

  5. Environmental factors
    • Units run 24×7
    • Errors occur randomly across different devices and locations

Termination resistors (120 ohms) are present at both ends. No other nodes are connected.

Any insights or suggestions on what could cause intermittent ACK errors without bus-off would be greatly appreciated.

  • 0
    TI__Guru 60827 points

    Hi Tirthraj,

    It seems the ACK slot is temporarily prevented from pulling dominant due to timing mismatch (noise or timing marginality ) where the transmitter do not detect a dominant bit in the ACK slot and signal error but keeps re-transmitting. Although the transmit error counter increases, it stops at 128 for an error and never reaches 256 for a bus off condition for example. Hence, with no additional error occurring, communication stops until issue is resolved and the counter naturally decreases and would recommend the below:

    • Re-evaluating your bit timing and sampling points as intermittency suggest marginality in bit timing sensitivities across variations from clock sources, temp or cable impedance. Check the controller's total time quanta per bit. I presume your sample point is > 75 %. Greater may work for longer bus lengths and would recommend 75 % for your 1 meter case. This should be a bit more robust to signal reflections. Recommend to use CAN bit timing calculators online to optimize the settings for the data rate and a 1 meter bus length. You may also scope TXD, RXD, CANH and CANL pins to observe.
    • Verify the controller's clock accuracy on both devices. Especially across temp variations.
    • May consider EMI from nearby equipment since running 24/7. Consider shielded pair cables or adding CMC.
    • Double check no GND shifts between the two nodes to ensure proper grounding.
    • Measure the bus impedance to ensure it is in fact 60 ohms. Ensure connectors are without any solder joint issues that can open due to temperature or vibrations that could lead to a temporary change in bus impedance leading to reflections and ACK errors, thanks.

    Best Regards,

    Michael.