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.

SN65HVD251-Q1: Slower CAN signal edges with new generation of build

Part Number: SN65HVD251-Q1
Other Parts Discussed in Thread: SN65HVD255, TCAN1057A-Q1, TCAN1044A-Q1

Hello,

we've been building CAN modules with the SN65HVD251QDRQ1 transceiver chip for years.  In our latest board revision, it is having issues communicating reliably in the system.  The overall length of shielded twisted pair wire is 80'.  We are running at 1Mbps, have two 120 ohm terminations (one at each end), and there are 11 nodes total.  We receive error frames with this new build, and never did before.  Examining with a scope, we see that the recessive, falling edge is slower in the newest build compared to the original build from 3 years ago.  When comparing capacitance of CAN-H and CAN-L in unconnected modules with a calibrated LCR meter, the old device measures less capacitance than the newer modules.  The capacitance goes away (to pF) when the transceiver chip is removed.  This circuit's schematic hasn't changed. Has the SN65HVD251QDRQ1 chip had any physical changes to it that may have increased the CAN H/L output capacitance or slowed down its edge rates?  Our circuit is below.

Bill

  • Bill,

    The schematic looks good, and there haven't been any changes to the process flow for this device, so it's strange that it is no longer working. 

    Can you share any waveforms you've captured? And what kind of errors is the controller reporting?

    Regards,

    Eric Hackett 

  • Hi Eric,

    I have lots of scope images and I'll pick a couple tomorrow.  The essential issue is we're getting Error Frames due to bit-stuffing errors when the CAN bus high/low (dominant to recessive) transition lags and the digital Rx take too long to transition from Low to High.  We (or another device) flags an error frame.  Then after repeated error frames, the controller goes offline.  We've experimented with increasing the slew rate by decreasing the Rs value (500 ohm) and that appears to fix the problem.  But on our previous generation boards we didn't need to change from the 10k Rs value.  ''

    We're buying some of the SN65HVD255 "turbo" transceiver parts to test with, which should also fix the issue.  But without an clear explanation on 'why' the edges are slower, our customer doesn't want to retrofit 100's of devices.  So we're still looking for a root cause for why the edges are slower


    Bill

  • Bill,

    We're looking into this, but this is a very old device where the design has not been touched in many years, so to hear that the edges are now slower in newer devices is not something we've heard from others. Can you please give the topside marking of the devices that are showing this behavior? I want to understand when and where they were built and see if there has been any change that we weren't made aware of.

    Regards,

    Eric Hackett 

  • Here are the chip markings:

    Works Well

    251Q1

    91M

    AER5G4 

    Has Frequent Error Frames

    251Q1

    33M

    A267G4

  • we found with our testing today that the SN65HVD255 device does fix things so that the network works correctly without error frames (ran with 3 devices over 80' for 5 hours, zero error frames).  The main issue is that our customer has delivered over 1000 units to their customer, so replacing parts on all of these would be very expensive.

  • here is the scope image of both ends of our 80' cable.  the blue signal is the TI 251 transceiver end, yellow at the far end connected to a USB adapter. You can see the slow decay (reflection, too?), and the immediate error frame going dominant when that recessive bit is heard as a dominant bit (staying high too long).  We're using differential probes to get good pictures of the waveforms.

  • Hi Eric,

    has there been any discoveries on the codes or manufacturing history?

    thanks!

    Bill

  • Bill,

    Thanks for your patience here. The older devices were built in 2009, and the newer devices were built in August of 2023. Looking through our change notifications, there was a new fabrication site qualified earlier in 2023 and this device was on the list to be affected. That being said, there was no report to us that any parameters shifted, and this may be because they are still within the datasheet range, or they weren't datasheet parameters tested, so there wasn't any shift noticed. I have not confirmed this yet, but the timelines line up with the old and new devices.

    The reason no one has reported is likely because most customers aren't running these devices at 1Mbps, so the delayed recessive edge doesn't have an effect on the receiver interpreting the bit correctly. It's good to here that the SN65HVD255 works without fail, but understood that it's inconvenient for the customer to call back all of the builds. 

    Is the reason the customer is using a device this old because it's a legacy design? I'm asking because we have 5V 8-pin transceivers with the same pinout that would work for future designs (TCAN1044A-Q1 or TCAN1057A-Q1) where this wouldn't be an issue. 

    I am working to confirm what validation data we have when the fabrication site change was made, and I will update you by Thursday. Again, thank you for your patience.

    Regards,

    Eric Hackett 

  • thanks for the update.  anything further from the manufacturing side?  Yes, the design has been qualified by our customer for use in a system, and replacing the part with a different one would require extensive EMC retesting.

  • Bill,

    Sorry about the delay here, I'm still trying to gather the information from the manufacturing teams.

    Regards,

    Eric Hackett