We’d been capturing CAN frames passively for weeks. But sending diagnostic requests — that’s a different game. The LilyGO ESP32 CAN board needs to transmit, not just listen.
The Hardware
The LilyGO T-CAN485 board uses:
- ESP32 microcontroller with built-in TWAI (Two-Wire Automotive Interface) CAN controller
- SN65HVD231 CAN transceiver chip (3.3V, high-speed capable)
- ME2107 boost converter for power
We wrote custom firmware using the ESP32’s TWAI driver. Frames received perfectly — 30+ per second of broadcast traffic from the car. But transmit? Nothing. The TWAI driver accepted our frames (TX OK), but no ECU ever acknowledged them.
The Debugging Odyssey
Attempt 1: Wrong pins?
We tried GPIO27/26, 5/4, 22/21, 16/17 — all received frames, none transmitted successfully.
Attempt 2: Wrong mode?
TWAI has LISTEN_ONLY mode (receive only, never acknowledge) and NORMAL mode (full TX/RX). We were definitely in NORMAL mode.
Attempt 3: Bus-off state?
After a failed TX with no acknowledgment, the CAN controller enters “bus-off” state. We added bus-off detection and auto-recovery. Still no TX.
Attempt 4: The transceiver RS pin?
We assumed the SN65HVD230 had an RS mode pin on GPIO4. Wrong chip — ours was the SN65HVD231. And GPIO4 is actually the WS2812 LED data pin.
Attempt 5: Read the actual schematic
We finally went to the source — the official T-CAN485 GitHub repository. The pin configuration file revealed two critical pins we had completely missed:
#define ME2107_EN 16 // Boost converter enable
#define CAN_SPEED_MODE 23 // CAN transceiver speed mode
GPIO16 powers the CAN transceiver through the ME2107 boost converter. We never set it HIGH — the transceiver was unpowered!
GPIO23 controls the SN65HVD231’s speed mode. LOW = high-speed (500kbps), HIGH = slope-control mode. We never configured it.
The Fix
Two lines of code in setup():
pinMode(16, OUTPUT);
digitalWrite(16, HIGH); // Power ON the CAN transceiver
pinMode(23, OUTPUT);
digitalWrite(23, LOW); // High-speed mode for 500kbps
That’s it. TX immediately started working. TX OK responses confirmed frames were now acknowledged by other ECUs on the bus.
Lesson
When working with development boards, always check the manufacturer’s pin configuration file. We spent hours debugging the ESP32 CAN controller when the problem was two GPIOs on the power supply and mode select lines.
Coming up in Part 9: building our own UDS diagnostic tool — ISO-TP transport, CAN ID auto-scanning, security unlock, and an interactive diagnostic shell.
Disclaimer: The information in this article is provided for educational purposes. Working with vehicle CAN bus systems carries risk of electrical damage and unintended ECU behaviour. Proceed at your own risk.
Leave a Reply