Arduino GIGA R1 CAN Bus Guide: Wiring, Transceiver, Termination and Arduino_CAN

Arduino GIGA R1 CAN bus guide: wire the STM32H747 CAN interface through a 3.3 V-compatible transceiver, add 120-ohm termination, use D93/D94, send and receive classic CAN frames with Arduino_CAN, and understand CAN FD limitations.

The Arduino GIGA R1 WiFi has CAN hardware built into its STM32H747XI processor, so you do not need an external CAN controller such as an MCP2515.

You do, however, still need a:

between the GIGA’s logic-level CAN TX/RX pins and the differential CAN bus.

The basic architecture is:

The current Arduino GIGA core exposes the primary CAN interface as:

and Arduino’s standard Arduino_CAN library provides a simple API for classic CAN frames.

Quick GIGA CAN Reference

Function GIGA R1 WiFi
Primary CAN RX D93 / PB5
Primary CAN TX D94 / PB13
CAN controller STM32H747 FDCAN hardware
External transceiver required Yes
Logic level 3.3 V
Arduino standard library Arduino_CAN
Standard CAN ID 11-bit
Extended CAN ID 29-bit
Default Arduino payload limit 8 bytes
Arduino bitrate presets 125, 250, 500, 1000 kbit/s
CAN FD through standard Arduino_CAN API No

GIGA Has the CAN Controller, Not the Physical Transceiver

The STM32H747 produces logic-level signals:

but a real CAN bus uses:

as a differential pair.

A transceiver performs the conversion:

Do Not Connect CANH/CANL Directly to the GIGA

This is one of the most important wiring rules.

Connecting the bus directly to PB5/PB13 would bypass the physical CAN layer and can damage or prevent proper communication.

Choose a 3.3 V-Compatible CAN Transceiver

The GIGA uses:

so choose a transceiver whose logic-side TXD/RXD levels are compatible with 3.3 V MCU pins.

For classic CAN, common choices include 3.3 V-compatible CAN transceivers designed for normal CAN 2.0 networks.

If you intend to use:

choose a CAN FD-rated transceiver rather than assuming every older classic-CAN transceiver will support the higher data-phase rates.

Basic Wiring

GIGA CAN transceiver
D94 / CAN TX TXD
D93 / CAN RX RXD
3.3 V or appropriate supply VCC / logic supply
GND GND

On the bus side:

Transceiver CAN network
CANH CANH
CANL CANL

Use a Twisted Pair

CAN is designed around a differential twisted pair:

This improves immunity to:

  • electromagnetic interference;
  • common-mode noise;
  • motor noise;
  • long-cable disturbances.

120-Ohm Termination

A normal CAN bus should have:

termination at each physical end of the main bus.

That means:

There should normally be:

on the complete bus, not one terminator at every node.

Measure About 60 Ohms with Power Off

A useful diagnostic is to disconnect power and measure resistance between:

on a correctly terminated bus.

Two 120 Ω terminators in parallel give approximately:

A reading around 120 Ω often indicates one terminator is missing.

A much lower value can indicate too many terminators or another wiring problem.

Keep Stubs Short

CAN works best as a:

rather than a star network.

Connect each node through a short stub to the main twisted pair.

As bitrate and cable length increase, long stubs become increasingly problematic.

Common Ground

For normal non-isolated transceivers, connect a reference ground between nodes unless the physical-layer design explicitly uses galvanic isolation.

CAN is differential, but the transceivers still have a limited common-mode voltage range.

A ground reference helps prevent that range being exceeded.

Install Arduino_CAN

The current Arduino Mbed core for GIGA includes support for:

The core instantiates:

for the primary GIGA CAN controller.

Start the CAN Controller

The library accepts predefined bitrates:

For example:

Every Node Must Use the Same Nominal Bitrate

If one node is configured for:

and another for:

they will not communicate normally.

Match the existing network bitrate before connecting the GIGA.

Standard CAN IDs

Classic standard CAN uses:

Arduino’s API provides:

for constructing a standard identifier.

Send a Standard CAN Frame

What CAN.write() Means

The Arduino CAN API documents:

as enqueuing a frame for transmission.

A return value of:

means the frame was accepted for transmission by the software/controller path.

It does not necessarily mean another node received and processed it.

CAN Requires Another Active Node for Normal Acknowledgement

On a normal CAN network, transmitted frames are acknowledged by another active CAN controller.

A setup containing only:

is not equivalent to a complete multi-node network.

For first tests, use:

  • a second CAN board;
  • a USB-CAN adapter;
  • another microcontroller CAN node.

Receive CAN Frames

The normal receive pattern is:

A simple receiver is:

Built-In CanMsg Printing

CanMsg implements Arduino’s printable interface.

So:

prints the identifier, length and data bytes in a useful debug format.

Read the Identifier Manually

For standard frames:

For extended frames:

You can check the frame type with:

Read the Data Bytes

Extended 29-Bit IDs

Extended CAN identifiers use:

Arduino’s API provides:

For example:

Standard vs Extended IDs

Use standard 11-bit IDs when the network protocol specifies them.

Use extended 29-bit IDs for protocols that require a larger identifier space, such as many:

  • automotive protocols;
  • J1939-style networks;
  • custom industrial protocols.

Do not change ID format arbitrarily; it is part of the network protocol.

Current Arduino_CAN Payload Limit Is 8 Bytes

The current Arduino core defines:

That means the standard Arduino_CAN API is currently using classic CAN payload sizing:

per data frame.

But STM32H747 Has FDCAN Hardware

This can be confusing.

The STM32H747 peripheral itself is:

but the current high-level Arduino Arduino_CAN wrapper constructs classic Mbed CAN frames with an 8-byte data limit.

Therefore:

Classic CAN vs CAN FD

Feature Classic CAN CAN FD
Maximum data payload 8 bytes Up to 64 bytes
Arbitration bitrate One nominal bitrate Nominal arbitration bitrate
Faster data phase No Optional
Standard Arduino_CAN on GIGA Yes No current high-level support

How to Use CAN FD on GIGA

If your project specifically needs:

you need a CAN FD-capable software path rather than assuming Arduino_CAN enables it automatically.

Options include:

  • a dedicated GIGA FDCAN library;
  • lower-level STM32/Mbed work;
  • a third-party CAN FD library designed for GIGA.

For example, the third-party:

library specifically targets the GIGA’s CAN FD hardware.

This is not the same as Arduino’s standard Arduino_CAN API.

Use a CAN FD-Rated Transceiver for CAN FD

Even if the MCU and software support CAN FD, the physical transceiver must also support the required data-phase rate.

For a new CAN FD design, choose a transceiver explicitly specified for:

rather than relying on an older classic-CAN transceiver.

GIGA Has a Second CAN Controller in the Current Core

The current GIGA Arduino variant defines:

and instantiates:

The primary interface is:

Second CAN Mapping

The current core also defines:

On the GIGA digital map these correspond to:

So an advanced application can potentially use a second CAN controller through:

instead of the dedicated D93/D94 CAN pair.

Second CAN Uses Multiplexed Header Pins

D16 and D8 are not dedicated CAN-only pins.

They also participate in other board functions.

For example:

So using CAN1 requires deliberate pin/peripheral planning.

Primary CAN Is the Simplest Choice

For a normal project, start with:

because those pins are explicitly assigned to the primary CAN interface in the board mapping.

Use CAN1 only when you actually need a second independent CAN channel.

Dual CAN Applications

Two CAN controllers are useful for:

  • gateway applications;
  • vehicle network bridges;
  • isolating machine networks;
  • protocol conversion;
  • logging one bus while controlling another.

A typical gateway architecture is:

Each CAN Controller Needs Its Own Transceiver

If you use two independent CAN buses, you need:

Do not connect two controller TX/RX pairs to one transceiver unless the hardware is intentionally designed for that purpose.

CAN on the M7 vs M4 Core

The GIGA has:

cores sharing the same hardware.

Give each CAN peripheral one clear processor owner.

For example:

Do Not Initialise the Same CAN Peripheral from Both Cores

Arduino’s dual-core documentation warns that shared peripheral access can cause interference.

Avoid:

on the same controller.

Choose one owner and communicate through RPC if the other core needs the data.

Current M4 CAN Caveat

The Arduino core declares CAN support for both GIGA cores, but there have historically been reported issues using the standard Arduino_CAN implementation from the M4 core.

For a production design:

  • test the exact current board-core version;
  • verify sustained transmit and receive operation;
  • prefer a known-good M7 implementation if reliability on M4 has not been validated.

This is especially important for safety-related or industrial applications.

CAN Bus Error Symptoms

Common symptoms include:

  • frames never received;
  • transmit errors;
  • controller repeatedly retrying;
  • bus-off state;
  • intermittent communication;
  • works at low bitrate but not high bitrate.

Check the Physical Layer First

Before changing code, verify:

Most first-time CAN problems are physical-layer or bitrate problems, not application code.

Use an Oscilloscope or CAN Analyser

Useful diagnostic tools include:

  • oscilloscope;
  • logic analyser with CAN decoder;
  • USB-CAN interface;
  • professional CAN analyser.

Measure both:

and:

to determine whether the problem is in the MCU, transceiver or network.

Typical First-Test Setup

Use:

for a simple first test.

Transmitter Test Code

Receiver Test Code

Common Mistake 1: No Transceiver

The GIGA’s CAN pins are:

not CANH/CANL.

Always use a physical transceiver.

Common Mistake 2: 5 V Logic on GIGA RX

GIGA is a:

so verify the transceiver’s RXD output is safe for the STM32H747 input.

Common Mistake 3: Wrong Bitrate

All nodes must agree on nominal CAN timing.

Start with one of Arduino’s supported standard bitrates:

Common Mistake 4: Too Many Termination Resistors

Do not fit:

at every node.

Normally terminate only the two physical ends of the main bus.

Common Mistake 5: No Second Active Node

CAN is not UART.

A lone node does not represent a normal acknowledged CAN network.

Use another active CAN controller for meaningful transmission testing.

Common Mistake 6: Assuming Arduino_CAN Means CAN FD

The hardware is FDCAN-capable, but the current standard Arduino message type is limited to:

and therefore represents classic CAN framing.

Common Mistake 7: Sharing CAN Between M7 and M4

One physical CAN controller should have one clear software owner.

Use:

to share higher-level data between cores.

Quick Wiring Reference

Quick Arduino_CAN Reference

Final Thoughts

The Arduino GIGA R1 WiFi is a strong CAN platform because the STM32H747 already contains the controller hardware.

For a normal classic CAN project you need:

The simplest software path is:

Remember the important distinction:

If you specifically need CAN FD, use a CAN FD-capable transceiver and a software library or lower-level driver that actually exposes the STM32H747 FDCAN features.

For full GIGA pin mapping, see our Arduino GIGA R1 WiFi pinout guide. If you want to place CAN on the M4 while the M7 handles networking or logging, also see the GIGA R1 M7/M4 dual-core guide.

Share your love