Building a Robot-Grade CAN-FD Gateway & Networked Firmware Writer with W6300 — "Bridge Writer"

In a robot system where multiple control boards share a CAN-FD bus, this board lets you update every board's firmware over a single network link. The entire wired Ethernet uplink is handled by WIZnet W6300.

• Developed by: Robot Research Club, Tokyo Metropolitan College of Industrial Technology (TMCIT), Arakawa Campus — ararobo 2026 team
• Main MCU: STM32H723VGTx (Cortex-M7)
• WIZnet product: W6300 (U2, LQFP-48) — Ethernet controller

Developed by the ararobo 2026A team, the Robot Research Club of Tokyo Metropolitan College of Industrial Technology (TMCIT), Arakawa Campus. (https://www.metro-cit.ac.jp/?utm_source=chatgpt.com)
This project appears to be part of a broader KOSEN Robocon robot development ecosystem, where multiple embedded boards, CAN-connected controllers, Jetson interfaces, power boards, and ROS2-side communication packages are developed as separate repositories.

1. What Is This Board?

A single robot typically packs several sub-control boards — motor drivers, sensors, power management — and ties them together over a CAN / CAN-FD bus. The pain point is maintenance: as the board count grows, pulling each one out to re-flash its firmware becomes a real burden.

Bridge Writer solves this "over the network, all at once." A host (PC or network) connects to Bridge Writer via Ethernet, Wi-Fi, or USB, and Bridge Writer relays firmware images and control commands to each sub-board over the CAN-FD bus. In other words, it is both a "network ↔ CAN-FD" gateway and a firmware writer that re-flashes the other boards on the bus remotely.

2. System Architecture

The "Ethernet / Wi-Fi6 / USB / CAN" support stated in the README is implemented with a dedicated device for each interface.

On top of that, the board includes a microSD (SDMMC) slot for storing firmware images, a debug UART, ADCs, and a wide-range power front end (USB-C PD, barrel jack, OKL-T/6 DC-DC) — making it ready to drop into a real robot.

In one line, this is a multi-interface gateway that accepts several host connections (wired / wireless / USB) and pushes them down to a CAN-FD field bus — and W6300 sits at the heart of the wired path.

3. The Role of W6300 — Why Choose It Over the MCU's Built-In MAC

There's a notable design decision here. The main MCU, STM32H723, has a built-in Ethernet MAC. Even so, the team chose the hardwired TCP/IP controller W6300 instead of the internal MAC + external RMII PHY + software TCP/IP stack (lwIP) combo. The firmware makes that intent clear.

(1) A single QSPI link does it all W6300 connects to the STM32H723's OctoSPI (in QSPI mode). A single high-speed serial interface offloads the MAC, PHY, and TCP/IP stack entirely to the external chip, simplifying both board routing and the host-side structure. The pin definitions in main.h confirm every W6300 status/control signal is wired — Link (LNK), Speed (SPD), Duplex (DPX), Activity (ACT), Collision (COL), Interrupt (INT), and Reset (RST).

(2) TCP/IP stack offload = real-time headroom Bridge Writer's core job is to stream firmware reliably over CAN-FD. With W6300 handling TCP/UDP/IPv4/IPv6 in hardware, the STM32 is freed from lwIP tuning and maintenance and can focus its CPU and memory on its actual work: CAN-FD relaying and firmware transfer.

(3) Determinism A hardwired stack has lower jitter and more predictable behavior than a software stack — a good match for a writer tool that must deliver firmware accurately and without interruption.

In short, W6300 owns the entire wired network uplink plus the TCP/IP stack on this board. Deliberately leaving the MCU's built-in MAC unused and filling that role with W6300 is a clear, intentional design choice.

4. Operating Scenario — Networked Firmware Update

Based on the system block (PlantUML) in the repository, a firmware update proceeds through the following stages, propagating from the host (Bridge Writer update logic) → relay MCU board → target board (Other Board).

1. Stop Connecting — safely halt ongoing operation
2. Update Board Request — tell the target board to enter update mode
3. Update Board ID — specify which board to update
4. Allow The Update — the target board replies that it's ready
5. Start Firmware Update — transfer and write the image

Here, W6300 carries the network segment between the host and Bridge Writer, while CAN-FD carries the field segment between Bridge Writer and each sub-board.

The CAN side is configured accordingly — two ports (FDCAN1, FDCAN3), CAN-FD frames (64-byte payload), 1 Mbps nominal, 20-entry Rx FIFOs. The 64-byte FD frame is advantageous for transferring firmware blocks compared to classic CAN (8 bytes).

5. Applications · Protocols · Industrial Targets

This board's structure goes beyond a student exercise — it maps directly onto a classic industrial "edge gateway" pattern.

Protocols handled

• Network side: TCP/UDP, IPv4/IPv6 (W6300 hardwired stack)
• Field side: CAN-FD (ISO 11898-1) — 64-byte payload
• Auxiliary: USB High-Speed, Wi-Fi 6

Core application pattern: "Ethernet (TCP/IP) front + CAN-FD field + remote firmware management" This combination is, in itself, a gateway that manages and updates fieldbus devices from the network. Direct application areas include:

• Robotics / motion control (this project's use case): centrally deploy and manage firmware across distributed motor/sensor nodes on CAN-FD
• Industrial automation: Ethernet-to-CAN gateways bridging PLCs/IPCs to field devices, device provisioning
• Mobility / AGV / autonomous robots: CAN-FD backbone with network-based diagnostics and flashing
• Factory mass-production & maintenance: fleet-wide firmware deployment over the network

Why W6300 fits this target W6300 is purpose-built to give MCU-class edge/field devices a lightweight, deterministic network connection. Adding TCP/IP to a device that speaks a fieldbus like CAN over a single SPI/QSPI link is exactly where it shines — in gateway applications that "put fieldbus devices on the network." Bridge Writer is a great reference that demonstrates this in the approachable form of a student robotics system.

6. Development Status (As-Is)

As of this writing, Bridge Writer is an ongoing project whose hardware and firmware scaffolding are complete around W6300.

• ✅ W6300 adopted on the PCB (v0/v1); RJ45, QSPI, and status/interrupt routing complete
• ✅ STM32-side W6300 pin/EXTI/reset GPIO initialization implemented
• ✅ CAN-FD driver (FDCAN1/FDCAN3, 64-byte FD) initialization working
• 🚧 The W6300 communication stack (QSPI driver, Ethernet driver class) is currently a stub — implementation in progress

In other words, it's accurate to read this as "the hardware design and the pin/bus definitions are finished around W6300, and the next step is filling in the network software stack." That is consistent with an active 2026 robot-club project.

7. Closing

Bridge Writer takes a practical goal — "manage the firmware of distributed boards over the network, all at once" — and solves it with a clean architecture of W6300 (Ethernet) + CAN-FD (fieldbus) + STM32H7 (relay). In particular, choosing the hardwired TCP/IP controller W6300 over the MCU's built-in MAC to gain real-time headroom and design simplicity is a useful reference for any maker or engineer looking to bring fieldbus devices onto a network.

Once the stack implementation is complete, it should become a fully realized gateway tool that "remotely flashes CAN-FD devices from Ethernet."

• Repository: https://github.com/tmcit-ararobo-2026a/bridge-writer
• License: MIT