TCAN332 communication with 5-V transceiver over backplane

Hi Andy,

(I thought this was a different enough topic that I split it into its own thread from where you originally posted at https://e2e.ti.com/support/interface/f/138/p/833450/3097745.  My hope was to make this easier to find for people who may be searching for a similar issue.)

Would it be possible to capture the CANH and CANL bus waveforms on an oscilloscope when this issue occurs?  Normally a CAN bus should be able to tolerate differences in recessive level across a transceiver's rated common mode voltage range (often +/- 12 V) as long as the differential magnitude is not affected.  So, I'm wondering if there may be some other issue related to either the dominant/recessive differential amplitudes or with the signal timing.  The best way to diagnose this would be with a waveform capture.

Regards,
Max

Below is CAN-H and CAN-L when the third party device is not powered on -- our device (MCU with TCAN332) is powered on/transmitting + only device on BUS. We get ACK errors (expected as only device on bus):

Below is when third party device is powered on and transmitting (assuming it has 5V transceiver with higher recessive + dominant states). Our MCU with TCAN332 is also powered on and reports form + stuff errors with no valid CAN receive status and then stops interrupting:

(Thanks!)

Thanks for providing these waveforms!  I see what may be supply ripple coupling though to CANH of the 5-V device (visible when the device output is dominant), but the differential signal levels look to be meeting the typical CAN bus requirements of dominant-state voltages >900 mV and recessive-state voltages <500 mV.  If you check the RXD output of the TCAN332, then, you should see it toggling in response to the output waveform from the 5-V device.  It would be good to take a look at that to verify that there aren't any obvious physical layer issues.

Since your node is reporting stuff errors and I see the data pattern does have a few periods where there are what look to be five dominant bits in a row, I'm wondering if there are maybe some timing marginalities in this link that are causing your node to detect six dominant bits during this five-bit period (this is what would be flagged as a stuffing error).  Here are some things to check:

 - What reference clocks are used for each node, and how accurate are they to their nominal rated freqeuncy?  If there is a wide variation in clock frequency it could lead to phase errors and mis-sampling of the bits in the MCU.

 - Have you checked into the CAN controller timing configuration in the MCU?  You may see some better results in adjusting the sampling point to be earlier or later within the expected bit period (or by adjusting parameters like the resynchronization jump width, particularly if there are clock frequency offsets).

 - Do you get different results if operating at faster or slower data rates?  It looks like you are operating at 250 kbps now; please correct me if that is wrong.

Also, although I don't see an issue related to the CAN lines at the moment it may be helpful if you could share a schematic showing your usage of the transceiver for us to review.

Regards,
Max