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: Design review

Part Number: SN65HVD230
Other Parts Discussed in Thread: SN65HVD231, , SN65HVD232, TCAN330

Hi team,

could you please review the following design? I am planning to use this CAN IC for communication between my car and ESP32 module.

The idea is to switch off the IC completely (CAN_ENABLE pin (GPIO HIGH/LOW) - 3,3V from ESP32 GPIO (max 40 mA)) when the communication is not needed to save some energy (internal battery is used - I am not using OBD2 12V pin). I know SN65HVD230 and SN65HVD231 offers some energy saving modes, but I would still prefer to shut down the IC completely.

If the design is OK, could you please tell me if it is a good idea to put a resistor between RS and GND pin, for example 10k? I have seen many application with such resistor, but I do not know the reason behind that.

I have also seen SN65HVD232, do you think it would be better option for my application (no RS and VREF pin)?

Thank you.

  • Hi Tomas,

    Let me start off by saying that you should take a look at our newer 3.3V can devices. The TCAN33x family is what you are looking for. We have multiple devices in that family that come with different low power modes like shut down, silent, and standby:

    The real benefit of this family of devices is the improved CAN driver that handle much higher speeds and worse loading conditions than the SN65HVD23x.

    Now, when it comes to your circuit, I would be worried about powering the IC off of a GPIO pin with only 40 mA of max current. For one, you could damage the GPIO if your CAN bus experience a fault and draws significantly more current than the GPIO can withstand. The current ratings shown in the datasheet are with no load:

    With an appropriate load on the bus you could see upwards of 50 mA of current when the bus is driving dominant. 

    It would be a better idea to just run your VCC off of the battery through an LDO or separate rail that can source more current, and then use the sleep feature of the SN65HVD231 to use very minimal current. As you can see from the image above in sleep mode the SN65HVD231 only use 0.04uA typical. So that is an extremely low current draw on the battery.

    The reason people use resistors on the Rs pin is because depending on the pull down resistance from 10K to 100K you can control the slope of the output driver. However, if you drive this pin to VCC you can put it in low power mode and that is where you will see very minimal current draw.

    For the SN65HVD232, if you want to think of a separate way to disconnect VCC, maybe by controlling the EN pin on an LDO that is supplying the rail for VCC, then you could use that device as you don't need a VREF pin or an RS pin to put it into a low power mode. I just don't like the idea of powering your VCC from a GPIO.

    Best,

    Chris

  • Hi Chris,

    thank you very much for your answer, great explanation! TCAN330 looks exactly like the right fit for my application, but unfortunately they are out of stock everywhere and it seems they will not be available for some time :/. Is there any chance to get them somewhere?

    If not, I think I will have to use SN65HVD232. I will implement either LDO with EN which turns on/off the CAN or some other sort of on/off circuitry.

    Thank you!

  • Hi Tomas,

    There are 220 of the TCAN330D in stock right now on TI.com. How many do you need?

    Best,

    Chris

  • Hi Chris,

    after some thinking I have decided to use SN65HVD232DR with controlled VCC, which will enable/disabled the IC completely. It seems like the most effective solution for me.

    Since SHDN pin of TCAN330 needs to be pulled HIGH for low-power mode, it would require some additional circuitry when using ESP32 sleep mode (output pins are low in deepsleep).

    Thank you!

  • No worries Tomas,

    Good luck and let me know if you have any questions.

    Best,

    Chris