CAN Communication Between Two Teensy 4.0 Boards Using SN65HVD232D – Loopback Works, External Bus Fails

Hi everyone,
I’m having trouble getting two Teensy 4.0 boards to talk to each other over CAN using SN65HVD232D transceivers. Internal loopback passes on both boards, but nothing is received over the physical bus.

Hardware Setup
ItemDetails
Microcontrollers2 × Teensy 4.0
Transceivers2 × SN65HVD232D
Termination120 Ω at each end
CAN pins testedCAN1 (22/23) and CAN2 (0/1)

Wiring (SN65HVD232D)
Transceiver PinConnection
1 (D)Teensy CAN_TX
2 (GND)Ground
3 (VCC)3.3 V
4 (R)Teensy CAN_RX
6 (CANL)Other transceiver CANL + 120 Ω
7 (CANH)Other transceiver CANH + 120 Ω
8 and 5 (NC)Nothing

Code
Sender

#include <FlexCAN_T4.h>
FlexCAN_T4<CAN2, RX_SIZE_256, TX_SIZE_16> can2;
CAN_message_t msg;

void setup() {
Serial.begin(115200);
delay(1000);
can2.begin();
can2.setBaudRate(125000);
Serial.println("Sender ready");
}

void loop() {
msg.id = 0x123;
msg.len = 1;
msg.buf[0] = 42;

if (can2.write(msg)) {
Serial.println("Sent!");
} else {
Serial.println("Failed!");
}
delay(1000);
}

Receiver
#include <FlexCAN_T4.h>
FlexCAN_T4<CAN2, RX_SIZE_256, TX_SIZE_16> can2;
CAN_message_t msg;

void setup() {
Serial.begin(115200);
delay(1000);
can2.begin();
can2.setBaudRate(125000);
Serial.println("Receiver ready");
}

void loop() {
if (can2.read(msg)) {
Serial.print("Received: ");
Serial.println(msg.buf[0]);
}
delay(10);
}

What Works

  • Internal loopback succeeds on both CAN controllers and baud rates.
  • Code builds and runs without errors.

What Doesn’t Work

  • No external CAN traffic detected.
  • Receiver never prints any messages.
  • Sender alternates between “Sent!” and “Failed!” after a few seconds.

Observations & Troubleshooting So Far

  1. Sender says “Sent!” even when transceivers are unplugged.
    → Seems can2.write() only confirms that a frame was queued internally, not that it was acknowledged on the bus.
  2. Tried baud rates 125 k, 250 k, 500 k — no change.
  3. Tested both CAN1 and CAN2, with and without FIFO/mailbox configs.
  4. Double-checked wiring, 3.3 V supply, and both 120 Ω terminators.

Questions​

  1. Is there a quirk with the SN65HVD232D I’m missing?
  2. Should can.write() return false if the frame isn’t acknowledged?
  3. Any known FlexCAN_T4 + SN65HVD232D issues?
  4. Would switching to something like an MCP2551 be more reliable?
 

Attachments

  • 1.jpg
    1.jpg
    252.3 KB · Views: 68
  • 2.jpg
    2.jpg
    285.8 KB · Views: 66
  • 3.jpg
    3.jpg
    249.5 KB · Views: 68
  • 4.jpg
    4.jpg
    340 KB · Views: 63
  • 6.jpg
    6.jpg
    202.9 KB · Views: 65
I would check the soldering on the SN65HVD232D. They don't look too good. Add some flux and reflow them.

You can't use the MCP2551 as it is 5v logic device. You will damage the Teensy.

You can use MCP2562.
 
I would check the soldering on the SN65HVD232D. They don't look too good. Add some flux and reflow them.

You can't use the MCP2551 as it is 5v logic device. You will damage the Teensy.

You can use MCP2562.
Thanks for pointing that out – I did go heavy on the solder. Continuity checks passed, but tht does not guarantee good high-speed signalling right? I’ll try to reflow the SN65HVD232D pins with flux and tidy them up with wick, then test again, i just didn't have a good soldering iron or skill aswell.

Yeah my bad i will try the MCP2562s if nothing else woks.
 
No decoupling on the chip's supply? 100nF across pins 2 and 3 is needed.
Thanks! I honestly didn’t think a 100 nF cap was necessary. Could you explain why the transceiver still needs its own capacitor right next to pins 3 (VCC) and 2 (GND)? I’d love to understand it better. Thanks again for the help!
 
I use the SN65HVD232D without any issues with the T4.1 on CAN 3. If you are by chance using the 231 or 230 variant instead of the 232, try grounding pin 8.

The decoupling/bypass capacitor across the chip power/ground pins is good design practice. With most circuit boards you will notice that at least one is put near virtually every chip.

The purpose is to provide a localized source of instant current to help handle any surge demands the chip may have and also helps to filter out noise on the power pin. This is even more important when the power is coming down a relatively long wire instead of a power plane right under the chip. Since your setup isn't working at all, it may not be the root cause of your issue, but it would still be good design practice to add one.

In fact the TI data sheet calls for both bypass and bulk capacitance near the power pin, so the chip may create fairly large power transients during switching. If you have a 1-10uF cap you might try tacking that on as well to see if it has any effect.
 
Thanks! I honestly didn’t think a 100 nF cap was necessary. Could you explain why the transceiver still needs its own capacitor right next to pins 3 (VCC) and 2 (GND)? I’d love to understand it better. Thanks again for the help!
High speed logic really is high speed. A few nanoseconds is the typical transition time, which means that a PCB trace can look much more like an inductor than a wire. Unless supplies are thoroughly decoupled the supply voltage seen at the chip can spike up or down by volts due to current changes hitting these inductances and triggering voltage spikes. Such spikes on the supply can cause malfunction within the chip - symptoms of inadequate decoupling are many and various and a real pain to figure out.

Thus you want to strongly stabilize the supply rails with caps right next to the chip (low inductance path to the silicon die is the key point).

Every supply rail should be decoupled direct to a ground plane ideally, values around 100nF are usual for logic, and must be MLCC (multi-layer ceramic) for low internal inductance.

As an example imagine eight 20mA LEDs switched by a logic buffer with a 3ns transition time. That's a dI/dt of about 53A/µs, so 5nH of stray inductance will induce about 0.25V. But 5nH is tiny, about the inductance of 1mm of typical PCB trace on a 2-layer PCB. 25mm of trace is over 100nH and will perhaps see a 5V spike. That's a problem in 3V logic(!!)

But you say, I don't have eight 20mA LEDs, so I'm good right? Alas no, that short timescale means that the stray _capacitance_ of tracks and IC pins will cause something like 20mA of initial current flow in response to the voltage transition for a few ns... Imagine 5V swing in 3ns into 10pF of stray capacitance - that's a charging current of 17mA (or 37mA if there is a 20mA LED as well!).

Now consider that 160mA spike for say 10ns, taking charge from a 100nF decoupling cap. That will lead to the cap discharging by only 16mV. So it really does strongly stabilize the supply voltage (so long as its only a few nH away from the chip pin). So although electricity propagates perhaps 60cm in 3ns on a PCB trace, if only takes a few mm of supply or ground trace to impede that propagation through its inductance enough to cause logic circuits to misbehave.

To add to the mystery many cheap 'scopes and probes aren't really fast enough to see this happening.
 
Last edited:
Quick update—even before I re-flow anything or add the 100 nF caps, I wanted to see what the bus actually looks like. I got hold of an old Hitachi V-552 (50 MHz) and scoped the lines exactly as-is (no solder rework, no extra decoupling, same breadboard wiring).


I grabbed four photos—just drag-and-drop them below (they’re the ones named osc2, osc3, osc4, os.jpg):
Shot #Probe pointWhat you’re seeing
1Same as #4 but zoomed-outRepeating 0x123 frame @ 125 kbit/s (overview)
2CANH/CANL right at the TX SN65HVD232DDominant ≈ 3.3 V / 1.3 V, recessive ≈ 2.5 V
3CANH/CANL right at the RX SN65HVD232DLooks basically identical to #2 → bus reaches 2nd node
4Teensy pins CTX (CAN_TX) & CRX (CAN_RX)CTX toggles, CRX stays recessive → no ACK

Observations
  • Edge speed looks a bit lazy (~2 µs on this analog scope).
  • Voltage levels seem in the ballpark (3.3 V / 1.3 V dominant, ~2.5 V recessive).
  • Still zero traffic getting through to the Teensy’s CRX pin.

Questions
  1. Are those edge times way too slow for 125 kbit/s, or is this just the scope bandwidth?
  2. Does the fact that CANH/CANL look good at the RX transceiver but not at CRX means “bad solder joint on the transceiver’s R-pin”?

Thanks again—just wanted to share real waveforms.
 

Attachments

  • osc4.jpg
    osc4.jpg
    315.5 KB · Views: 61
  • os.jpg
    os.jpg
    96.6 KB · Views: 63
  • osc2.jpg
    osc2.jpg
    79.7 KB · Views: 55
  • osc3.jpg
    osc3.jpg
    267.4 KB · Views: 49
No termination resistors? That's very slow recovery The recessive state looks wrong too, should be about mid-rail. One end seems to have much stronger drive than the other I think. Look at the 'scope shot at the end of this wikipedia page to see what you should expect: https://en.wikipedia.org/wiki/CAN_bus

But I see the two 120 ohm resistor in the photos, so its mysterious...

Might be worth getting screen captures for each side independently to check both CAN chips are behaving the same.

[ edit: But thinking about the differential signal, its clean and this untidy waveform shouldn't be preventing communication - the datasheet mentions the recessive state is not symmetrical, I guess the recessive bias network is very high impedance to give those slow exponential decays, not that there is much common-mode capacitance on a 100mm CAN bus segment! ]
 
Last edited:

Attachments

  • Screenshot 2025-08-08 130427.png
    Screenshot 2025-08-08 130427.png
    242.9 KB · Views: 50
  • Screenshot 2025-08-08 130432.png
    Screenshot 2025-08-08 130432.png
    159.2 KB · Views: 44
Your CAN_H and CAN_L doesn't look right.

For 125k, it should look something like this:
Blue : CAN_H
Red : CAN_L
Green : CTX2
Yellow : RX2
Code:
msg.id = 0x7DF;
msg.len = 8;
msg.buf[0] = 0x01;
msg.buf[1] = 0x23;
msg.buf[2] = 0x45;
msg.buf[3] = 0x67;
msg.buf[4] = 0x89;
msg.buf[5] = 0xab;
msg.buf[6] = 0xcd;
msg.buf[7] = 0xef;
Screenshot_08_08_2025__21_38.jpg
 
Back
Top