TCAN1044-Q1: TCAN1044-Q1 VIO

Hi Jasper,

This is an interesting find. The Vio supply in this case should only impacts the threshold and output voltage of the digital IO pins. With a large series resistor on this supply, I suspect that the perceived Vio voltage is lower, and thus the threshold and output voltage are also lower. I'm not sure how this would impact CAN data, but it could certainly change how the digital signals TXD and RXD are interpreted and driven. 

Would it be possible to capture scope shots of the TXD and RXD signals during communication? It would be good to see this with a 0-ohm and a 10k-ohm for R73, though I am more interested in the a-typical 10k-ohm case. Please also measure the voltage at Vio during communication. 

Also, for this test is there anything else on the CAN bus besides TCAN1044V and the PCAN device?

Regards,
Eric Schott

Hi Eric

Sorry for late response. I have checked with my teammates.

Here shows the snapshots with R73 = 0 ohm:

The VIO is stable when CAN_H/L are correct signal, but sometimes can observe abnormal status(CAN_H/L) and VIO looks like with some interference.

And here shows the snapshot with R73 = 10k ohm:

In this test case, we can observe that the VIO dropped when CAN transmit or receive data, but CAN signal are correct. 

There are only TCAN1044V and PCAN device in the CAN bus.

Thanks.

Jasper

Hi Jasper,

Thanks for sharing the extra info and scope shots. 

The "Abnormal signal" shown here is an error frame. This consists of at least 6 consecutive dominant bits and can be driven by multiple nodes simultaneously. For this reason, it's common to see a larger differential voltage during an error frame. 

The analog CAN signal in the third image looks good, so I don't expect the error to be occuring the CAN bus side of things. It seems likely to me that there is some misinterpretation happening on the CAN controller side. The fact that changing the Vio level corrects this makes me think it has to do with the digital TXD and RXD lines. 

I would recommend looking at the TXD and RXD signals on the driving node and capturing the signal states during the error frame at a similar timescale shown above (2us/div) This will let us see if there is any ringing or noise on the RXD line that may have caused an error to be detected. 

Regards,
Eric Schott

Hi Eric

Here shows the TXD/RXD signal:

Do you have any idea about TXD and RXD have different signal in the snapshot which will cause the error frame?

Thanks.

Jasper

Hi Jasper,

The TXD signal here is driven by the local CAN controller and causes the TCAN1044 to drive the CAN bus to a dominant state (CANL low). When we see TXD is high while the RXD signal and CAN bus are dominant, this means a different node is driving this bus state. In this case, a different node has recognized some problem with the TCAN1044's transmission and has driven an error frame on the bus. 

Do you have access to the error codes from the other nodes on the bus? It would be good to know what error the remote node has detected that caused it to drive an error frame.
Can you share a block diagram of all of the devices that are on this CAN bus? Is it only the two nodes (TCAN1044 and one other PCAN)? If so, what is the other device?

Regards,
Eric Schott

Hi Eric

We only connect TCAN1044 and PCAN on this CAN bus, so we don't have another node to access the error code. (By the way, the TCAN1044 transmits the CAN data to the PCAN, and PCAN just receive the CAN data.)

Thanks.

Jasper

Hi Jasper, 

The scope shot shown above definitely shows multiple active transceivers on the CAN bus. This is evident by the CAN bus being dominant while the observed transceiver's TXD line is high. This can only occur if some other transceiver is being driven dominant at this time, presumably in response to the frame driven by TCAN1044 in this case.

I presume the PCAN device has a CAN controller associated with it. Even if the PCAN ECU is only set up to receive CAN frames, it will still contribute ACK bits and error frames in response to what it receives. I believe this, or perhaps some other active CAN node (sniffer maybe?), is detecting some problem with TCAN1044's transmission and driving an error frame accordingly. I do not see how this would be related to the Vio supply of the TCAN1044, unless this supply was somehow related to the receiving node as well. 

The waveforms driven by TCAN1044 look good in both cases where Vio is shunted and limited. I believe we will learn more about the source of this issue by looking at the receiving node. We can confirm that the PCAN node is driving this error frame by monitoring its TXD and RXD signals while the TCAN1044 is driving. I would expect to see the TXD signal remain high for the entire transmission and drive either 1 dominant (low) bit for an ACK or 6 consecutive dominant bits for an error frame. Seeing what data shows up on RXD will also help us identify if there is a problem on the receiver-side of the data frame. 

Getting the error code from this node to see what the source was would be helpful, but doing so is not always easy. I think the steps above would help gather most of the information we need to discern the cause ourselves, but there may still be somewhere else to look after this. Let me know if there is some other aspect of the system you think we should also take a look at. 

Regards,
Eric Schott