TWAI driver refusing to receive any valid packets

[DonaldP]

# ESP32-P4 TWAI Driver — Test Report & Fault Analysis
**Date:** 4 June 2026
**Hardware:** Guition JC-ESP32P4-M3-DEV (x2) — silicon rev v1.0 (COM9) and v1.3 (COM13)
**Firmware:** IDF v5.5.4, twai_p4_test v2.0
**Author:** Don, Richards Bay ZA

---

## 1. Test Installation

Two Guition JC-ESP32P4-M3-DEV boards wired crossover, no transceivers:

- Board A GPIO5 (TX) → Board B GPIO4 (RX)
- Board A GPIO4 (RX) ← Board B GPIO5 (TX)
- Common GND
- Pull-up resistors fitted: 3.3kΩ from GPIO4 to 3.3V on both boards

**sdkconfig required for TWAI ISR to function at all:**
```
CONFIG_TWAI_ISR_CACHE_SAFE=y
CONFIG_TWAI_IO_FUNC_IN_IRAM=y
CONFIG_FREERTOS_IN_IRAM=y
```

---

## 2. Chronological Test Sequence

### Phase 1 — TWAI Legacy Driver (IDF v5.3.5, iveco_suspension)
- Platform: Waveshare ESP32-P4-NANO, TWAI0 TX=GPIO22, RX=GPIO20
- Result: rx_err=129–135 in NORMAL mode. Bus never achieved error-active state.
- Conclusion: GPIO matrix routing for TWAI RX broken on P4 v1.x with legacy driver.

### Phase 2 — New TWAI Driver Bring-up (IDF v5.5.4, Guition boards)
- Driver API: `esp_twai.h` / `esp_twai_onchip.h`
- Internal loopback (`enable_self_test=1`, `enable_loopback=1`, TX=RX=same pin):
**10/10 PASS on both boards** — TWAI peripheral hardware confirmed functional.
- ISR callback confirmed firing: rx=10, err=0.

### Phase 3 — ISR Diagnosis
- Without `CONFIG_TWAI_ISR_CACHE_SAFE=y`: ISR callback never fires (ESP_INTR_FLAG_IRAM
not set, interrupt cannot fire during flash cache access).
- After setting `CONFIG_TWAI_ISR_CACHE_SAFE=y`: ISR fires correctly.
- Root cause of all prior loopback failures: wrong sdkconfig, not hardware.

### Phase 4 — GPIO Crossover Wire Verification
- Both boards drive GPIO5 as output, read GPIO4 as input simultaneously.
- Result: TX=0→RX=0, TX=1→RX=1, TX=0→RX=0 — **PASS on both boards**.
- Physical wiring and GPIO drive capability confirmed correct.
- Scope measurements on GPIO pins: correct CMOS levels, clean edges.

### Phase 5 — Two-Board TWAI Crossover (enable_self_test=1, enable_loopback=0)
- TX=GPIO5, RX=GPIO4, crossover wired, pull-up resistors fitted.
- Result: **FAIL — ISR rx=0, err=36–47 per 10 frames**.
- TX succeeds (no TX failures), frames are transmitted.
- Receiving board ISR fires only for error events, never for RX.

---

## 3. Analysis of Crossover Failure

The TWAI controller operates in self-test mode (`enable_self_test=1`) with external
loopback disabled. In this configuration:

- The controller transmits frames normally via the GPIO matrix to GPIO5.
- It monitors GPIO4 for the received signal.
- It performs bit-by-bit comparison of transmitted vs received data.
- CAN bit timing requires the RX pin to reflect dominant (LOW) during dominant
bit transmission and recessive (HIGH) during recessive.

**Observed:** err=36–47 errors per 10 frames. This rate (3–5 errors per frame)
is consistent with the controller detecting bit errors on every frame — meaning
the GPIO4 RX input is not correctly reflecting the transmitted signal levels
as seen by the TWAI controller's internal sampling logic.

**Scope confirmation:** GPIO5 TX output shows correct 3.3V CMOS levels.
GPIO4 on the receiving board receives the signal. The GPIO crossover wire test
(plain GPIO mode) passes. The signal is electrically present.

**Conclusion:** The TWAI controller's RX input sampling on P4 v1.x does not
correctly sample the GPIO matrix input in `enable_self_test=1` + `enable_loopback=0`
mode. The GPIO matrix routing for TWAI RX is broken in this configuration on
P4 v1.x silicon. This is the same fault observed in Phase 1 with the legacy driver.

**Espressif reference tests confirmed:** The official `test_twai_network.cpp`
does not test direct GPIO-to-GPIO two-board communication. All Espressif
two-board network tests use a USB-CAN adapter with transceiver hardware.
The `enable_self_test=1` + `enable_loopback=0` combination is not validated
in any Espressif reference test.

---

## 4. Proposed Production Circuit — TJA1055/3 and TJA1044/3

### B-CAN (125 kbps Fault-Tolerant) — TJA1055T/3
Used on: iveco_bcan node (FireBeetle ESP32-E), iveco_suspension (Waveshare P4-NANO)

```
ESP32-P4 GPIO (TX) ──► TJA1055T/3 TXD
ESP32-P4 GPIO (RX) ◄── TJA1055T/3 RXD ── 3.3kΩ pull-up to 3.3V (REQUIRED)
TJA1055T/3 RTH ── 100Ω ── CANH
TJA1055T/3 RTL ── 100Ω ── CANL
STB = 3.3V (normal mode)
EN = 3.3V (normal mode)
VCC = 5V, BAT = 5V
```

Split termination 100Ω RTH + 100Ω RTL to bus is **required** — removal triggers
vehicle fault detection on Iveco B-CAN.

### C-CAN (500 kbps High-Speed) — TJA1044/3
Used on: iveco_suspension (Waveshare P4-NANO TWAI0)

```
ESP32-P4 GPIO (TX) ──► TJA1044/3 TXD
ESP32-P4 GPIO (RX) ◄── TJA1044/3 RXD
TJA1044/3 CANH ── bus
TJA1044/3 CANL ── bus
S = GND (high-speed mode)
VCC = 5V
```

SLNT pin hardwired to 3.3V permanently to prevent CTX glitch on boot.

---

## 5. The Unresolved Problem

**On ESP32-P4 v1.x silicon (both v1.0 and v1.3), the TWAI peripheral GPIO matrix
routing for the RX input does not function correctly in normal (non-loopback) mode.**

Evidence:
- Legacy TWAI driver (IDF v5.3.5): rx_err=129–135, never achieves bus communication.
- New TWAI driver (IDF v5.5.4): err=36–47 per 10 frames, rx=0 in crossover mode.
- Internal loopback (GPIO matrix bypassed): 10/10 PASS — peripheral core is healthy.
- Physical GPIO crossover wire test: PASS — signal is electrically present at pin.
- Scope confirms correct signal levels on both TX output and RX input pins.
- Pull-up resistors fitted on RX: no change to failure mode.

The GPIO matrix routing for TWAI RX on P4 v1.x does not correctly connect the
physical GPIO pin input to the TWAI peripheral's RX input when operating in
normal bus mode. This is a silicon errata or driver bug specific to P4 v1.x.

This fault prevents TWAI from being used for real CAN bus communication on
ESP32-P4 v1.x boards regardless of transceiver hardware, signal quality,
or pull-up configuration.

**Affected boards:** All Guition JC-ESP32P4-M3-DEV and Waveshare ESP32-P4-NANO
units with ESP32-P4 silicon revision v1.0 and v1.3.

**Expected resolution:** Espressif to confirm whether P4 v1.x TWAI GPIO matrix
routing is a known errata, and whether IDF v5.5.4 contains the required workaround.
Waveshare to confirm whether ESP32-P4-NANO boards are available with v3.x silicon
where this issue is reported resolved.

---

## 6. Workaround Status

The only confirmed working TWAI operation on P4 v1.x is internal loopback
(`enable_self_test=1`, `enable_loopback=1`, TX=RX=same pin). This proves the
peripheral works but cannot be used for real bus communication.

No firmware workaround has been found for the GPIO matrix routing fault.
The `esp_rom_gpio_connect_in/out_signal()` approach used in the legacy driver
workaround (iveco_suspension) has not been ported to the new TWAI driver API
and Espressif has not published an errata fix for v1.x silicon.

[Sprite]

I doubt it's the GPIO matrix - if that were to be broken, you wouldn't see any packets to begin with, and the matrix is a pretty simple and tested and tried peripheral. What does your hardware look like? (As in: show a picture, post PCB designs etc)

[mikemoy]

Pull-up resistors fitted: 3.3kΩ from GPIO4 to 3.3V on both boards

Why do you have a pull-up on a CAN interface ?