• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 642 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SN65HVD234: Temperature issue with bad ACKN

Lutz Naumann
Expert 6110 points
Part Number: SN65HVD234

Dear team,

our customer is facing a temperature issue with the SN65HVD234 at could temp. Attached please find an explanation as a starting point. I also received measurements that I can send offline. Here is the description of the behavior: 
 
We are doing final thermal qualification of a new product before it's release for sale and we are experiencing a CAN bus issue that we don't understand.  Our product is using CAN bus on the backplane with termination at the ends. The backplane is short (less then 1 meter) and running transmission lines on multi-layer PCBs.

The CAN network under test has one manager and 12 devices so it's a small network.

The problem seems to occur at cold temperatures around -40C although it's not an absolute trip point.  The system has run as cold as -60C and appears to be stable.

The system under test has one particular card plugged into the backplane that appears to cause CAN bus failures with its immediate neighbor although there are multiple cards plugged into the network that are not directly affected.

The symptom causing a problem on the CAN network is a bad acknowledge bit.  The neighbor of the suspected card sends out a response to a message from the backplane manager, but the acknowledge signal does not drop correctly and remains high too long.  As a result, the bad acknowledge results in the CAN controller's auto-retry mechanism kicking in and flooding the networks with repeated messages.  The CAN controller is part of the STM32F105 MCU.

We suspect there is one specific card that is causing the issue because when we remove the suspected card the bad ACK no longer occurs on the neighboring device.  However, if it is true that one device is causing problems with a direct neighbor, it is strange that there is no bad ACK on any other module on the network. 

We have to release this product ASAP so any assistance you can provide to help us resolve this is greatly appreciated.  Let us know if it would help to do a conference call or webex to provide further explanation.

Pleas advice how to proceed!

Lutz

  • 0
    TI__Guru 62910 points
    Hi Lutz,

    I'd be interested in reviewing the measurements you mentioned if you can email them to me. From the info above, I understand that the issue is that the second recessive but of the recessive-dominant-recessive ACK delimiter is not reaching a suitably low differential voltage in time. This is a common issue in CAN buses, since multiple nodes can drive the dominant ACK bit simultaneously and this results in a higher differential amplitude for that bit. The bus then takes too long to fully "decay" to a recessive level. Since the driver output impedance and recessive biasing strength will vary with temperature, issues with this delimiter may only show up at certain temperatures.

    There are a few strategies for resolving this. One is to change the sampling point configuration in the CAN controller so that it is nearer to the end of the bit, allowing additional time for the dominant-to-recessive transition. Another is to reduce the effective load resistance of the bus (e.g., by adding higher-impedance termination on some nodes). This reduces the ACK bit amplitude a little and speeds up the transition to the recessive state, but care should be taken not to impose a load impedance smaller than the driver can support. Another strategy is to try to reduce capacitive loading as much as possible. (Some nodes may have additional capacitance added to achieve filtering, and if so these capacitances can be reduced or removed.) Another solution is to operate at a lower data rate, although I realize that solution may be less attractive.

    Regards,
    Max
  • 0 in reply to Miguel Robertson
    TI__Expert 6110 points
    Thanks Max,

    I forward you the plots separately.

    Lutz