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.

What kind of data send by CAN Bus Transceiver

Other Parts Discussed in Thread: TCAN4550-Q1

I am supporting a product that uses the TI CAN Transceiver SN65HVD234D.

From the schematic, I don't see any third party's CAN Controller. We are using an older ST-Micro ARM9 MCU chip. Its seems to have built-in CAN Controller as one of the multiple choices for configuring a port.

However, the MCU port's RX/TX pins, directly connected to the transceiver's CANH/CANL, are configured as UART port's RX/TX pins, not as CAN's RX/TX.

In software, the data sent to those port are direct data bytes, just as sending to a serial terminal UART port. I was told we don't use the CAN protocol, but only use the CAN transceiver to communicate normal serial data to take advantage of the CAN Bus noise tolerance.

My question is, in such connection, are the data sent between to CAN transceivers the CAN frame ? Does the transceivers convert UART data to CAN frames before sending them ? If so, does that mean the transceiver implements the CAN protocol? If not, what kind of data send on the CAN bus line?

Thanks for any help.

Jim

  • Hi Jim,

    The transceiver just converts between the single-ended logic signaling on TXD/RXD and the differential bus signaling on CANH/CANL.  It doesn't do anything to modify the data, it just changes the physical representation of the data on the line.  You can think of the function similar to a level shifter.

    It is OK to use a CAN transceiver for UART communication as you've described, but not if the application requires use of the CAN protocol (including proper data framing, arbitration, error checking, etc.).  For that you would need a CAN controller.  The controller performs all these data link layer functions and provides the TXD/RXD interface to a transceiver.  A controller may be integrated into another device like an MCU/uP (i.e., if those devices feature a CAN port), but if not there are discrete controller devices available as well such as TCAN4550-Q1.

    Please let me know if this is still unclear or if you have further questions.

    Regards,
    Max

  • Hi Max,

    Thanks for your response. That settles a puzzle I had for a while. Greatly appreciate your answer!

    Jim

  • Hi again,

    Based on your description, I am assuming the CAN transceivers, without CAN controllers involved, will not have the ability to resolve collision as described by the CAN protocol's collision resolution algorithm. It is basically a raw PHY layer transmission.

  • I went back read your comment again and notice you have already answered my question. So ignore the above comment from me.

    But I have another related question. I read from some documentation the CAN transceiver does a loop back for transmission confirmation. Do you think it is only certain chip maker's design, or popular CAN transceiver function. Without CAN controller, I would think looping back to the transceiver is useless. It will have to loop back to the MCU, correct?

  • Hi Jim,

    It sounds like you have a good understanding on the collision resolution topic, but just in case it helps to clarify - the CAN physical layer (implemented by the transceiver) does not detect collisions but it does ensure that they result in a predictable outcome.  That is, if any node on the bus transmits a "dominant" state, the bus will be considered dominant (RXD outputs low at each node).  (You could contrast this to other physical layers like RS-485, where if two active drivers send opposite bit values on the line it results in an indeterminate state.)  It's the controller, though, that is responsible for detecting that there is a mismatch between what it is sending on TXD and what is received on RXD and classifying it as a collision.  This is what is referred to as arbitration in CAN and allows for priority order to be automatically established between coincident frames based on their header information (specifically the identifier field, in which lower numeric values are considered to take higher priority).

    From this previous description you can probably see why the "loopback" function in the transceiver is important.  By loopback I mean that the receiver portion always reports the perceived state of the bus (recessive/high or dominant/low) even while the transmitter is active.  This allows for arbitration/collision detection to occur and also is useful for the transmitting node in confirming that the frame data being sent is represented properly on the bus.  Otherwise, for example if there are short-circuits or other fault conditions on the physical wiring, it would detect that there is a transmission error and act accordingly - for example, by re-sending the frame or (if many successive errors are recorded) transitioning itself to a passive/off state so that it does not prevent other nodes from communicating on the bus (e.g., in case this transmitting node is malfunctioning).

    Because it is critical to the data protocol, all transceivers will implement loopback in this way.  Note also that there are a small number of transceivers available that feature an additional loopback mode (sometimes referred to as autobaud loopback or detection) which creates an internal loopback path with the external CANH/CANL connection disabled, but this is kind of a specialized case and not what I believe you are referring to.

    Regards,
    Max

  • Hi Max,

    Thanks again for your in depth explanation. In our design, the MCU always receives the data from loop back. Software use the data to determine if there has been collision or not, and implements an algorithm to resolve the collision - very similar to the CAN bus arbitration. I will need to complete my homework to find out how the loop back is sent to the MCU.

    I am very lucky today, not only having you who has thorough knowledge of the subject, but also that you having a very clear style of writing and explaining the technical subject.

    Again, I am very grateful for your time and  knowledge.

    Jim