• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 326 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.

TCAN1042-Q1: FMA Test

Allan Fan
Expert 7410 points
Part Number: TCAN1042-Q1
Other Parts Discussed in Thread: TCAN1044A-Q1, , TCAN1042V-Q1

Hi expert,

Customer used TCAN1042 and test FMA for CHAH&CANL short to VCC. Requirement shall be minimum class C according to the ISO16750.

From the spec showing below, Class C should be able to return automatically to normal operation after the test. 

However, in customer's test, the CAN communication can't turn back to normal after the short test unless POR. 

Do you have any ideas what might be wrong during the test or advise any way can reset the part but not POR? 

Regards,

Allan

  • 0
    TI__Mastermind 26836 points

    Allan,

    First, I recommend using the TCAN1044A-Q1 instead of the TCAN1042-Q1, as the TCAN1044A-Q1 is the newer device and will have increasing supply over time to support new projects.

    Are you using a CAN controller to implement communication during the test? When a bus fault is applied, it is likely that there will be communication interruption that prevents any device from transmitting on the bus. This is not unique to the TCAN1042-Q1. After a device fails to communicate for long enough, eventually the node enters a bus-off state. This is a protocol behavior - not a TCAN1042-Q1 behavior.

    I imagine that there is a difference between TCAN1042-Q1 classification and full system classification for the node. The TCAN1042-Q1 should be able to resume transmitting on the bus once the short to supply is removed. Have you examined the TXD line to see if the controller is still attempting to transmit onto the bus? If the TXD line shows no data, then this would indicate that the controller has stopped transmitting rather than there being an issue with the TCAN1042-Q1.

    Best,

    Danny

  • 0 in reply to Danny Bacic
    TI__Expert 7410 points

    Danny,

    Yes, customer used CAN controller to implement communication during the test and they do examined on the TXD line and it's still attempting to transmit on the bus. Could you please advise what else might cause the issue?

    There is another questions is customer toggle STB pin (default is pulled low), but CAN controller would be stuck and need to reset to turn back CAN communication. We thought pull STB high will just let TCAN transceiver enter standby mode and should turn back normal operation after pulling STB low. Is the behavior expected? 

    Regards,

    Allan

  • 0 in reply to Allan Fan
    TI__Mastermind 26836 points

    Allan,

    Allan Fan said:
    they do examined on the TXD line and it's still attempting to transmit on the bus. Could you please advise what else might cause the issue?

    This is interesting. Have you verified that VCC is high and STB is low? (If using TCAN1042V-Q1, also confirm VIO.) With TXD toggling we would still expect to see the bus being driven. If you are able to confirm those pin states, then an oscilloscope shot of TXD and CANH/CANL on the same screen would be most helpful.

    Allan Fan said:
    There is another questions is customer toggle STB pin (default is pulled low), but CAN controller would be stuck and need to reset to turn back CAN communication.

    To be clear, the STB pin has an internal pull-up, not pull-down. Did you mean default low for your test?

    Allan Fan said:
    We thought pull STB high will just let TCAN transceiver enter standby mode and should turn back normal operation after pulling STB low. Is the behavior expected? 

    Yes, this is the expected behavior of the device.

    Best,

    Danny