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.

SN65HVD230: CAN Bus Hangs up

Part Number: SN65HVD230


I am using a 3.3V sn65hvd230 with ESP32 MCU.  I have programmed MCU to transmit frames continuously. Initially, everything is ok but after a day CAN bus hangs Up. Voltages of CANL , CANH are  2.25V and 2.25 Volts.


Note: MCU didn't hang up, I verified it with Bluetooth

  • What exactly do you mean with "hangs up"? This transceiver works on the electrical level only; the R and D pins always correspond to the bus state.

  • Hi Mounish,

    To verify the transceiver's behavior, can you capture scope shots of the TXD pin and the CAN bus (CANH, CANL)? This way we can see if the transceiver has stopped transmitting the incoming signal from the MCU or if the MCU has stopped attempting to send data on the TXD line. 

    If the latter is true, it may be due to some error occuring on the CAN controller side (MCU). If this is the case, you can read the associated interrupt registers from the CAN controller to identify the source of the issue that likely caused a bus-off condition and transmission to cease. Let me know if you need help identifying what a certain error means and how this impacts the transceiver itself. 

    Eric Schott

  • I mean voltage on H and L with respect to the ground are the same after a day. The condition is the same when two lines are shorted. Looks like Bus is going to BUS off state.

    I am using CAN for Battery. It takes some days for the end-user to use it actually but MCU keeps on sending frames without any receiver, does this push CANbus to BUS-off state?

  • Hi ERIC, 

    Is it ok to send CAN bus frames continuously without any receiver? I guess CAN-bus is going to BUS-OFF state

    As CAN is connected to Battery It takes some days for the end-user to actually use the CAN. 

  • When that happens, is there still a valid signal at the D pin? (This is what Eric asked for.)

  • Hi Mounish,

    Typically the BUSOFF state only occurs when the transmitting CAN node receives enough errors during transmission. This typically does not include ACK errors (where no other node responds to the message), but the firmware may deal with this case differentially. Other errors may occur when no receiver is present because the transmitting node also acts as a receiver to verify the data sent on the bus (but it will not ACK). Therefore if there is a bit error that appears during transmission, the lone node may still move to BUSOFF state after enough errors accumulate. 

    The firmware can be set to start the BUSOFF recovery sequence so that the controller can return to an operational mode after the BUSOFF state is reached. The rest of the sequence happens automatically and simply waits for enough instances of an idle bus to be detected. This would require the firmware to recognize when the CAN controller reaches this BUSOFF state and clear it so that the controller may begin the recovery sequence. 

    The debug the CAN transceiver itself, it would be helpful to see the TXD signal and the CAN bus. This will let us verify if the transmission stops because the transceiver stops responding. However, it sounds more likely that this behavior originates at the CAN controller, so you may want to focus your efforts debugging this area instead. Sharing CAN waveforms with us would also allow us to comment on if the transmission looks like it may cause transmission errors when no receiver is present. 

    Eric Schott