Fixing Missing Routed Traces

F

fredotheo

The "Airwires" review flagged a error on ADHESION_1:P1, ADHESION_2:P1.
Reports missing routed traces between pads in a net.
Designators: ADHESION_1:P1, ADHESION_2:P1; Net: +BAT_RAW
Context: Reports missing routed traces between pads in a net.
Help me fix this.

flux

This error means Flux sees pads on the same net that are not physically connected by routed copper. That is exactly what the Airwires check reports: missing routed traces between pads in a net
For your specific case:
  • ADHESION_1 P1 is on the Top layer
  • ADHESION_2 P1 is also on the Top layer
  • Both P1 pads are assigned to the same net, +BAT_RAW
  • So the fix is to route copper between those two pads, or remove/change the net assignment if they were not meant to be connected
What to do:
  1. In PCB view, select the airwire for +BAT_RAW between ADHESION_1 and ADHESION_2.
  2. Route a trace on the Top layer from P1 to P1.
  3. Recheck the review.
Important:
  • Your layout has plenty of board space, so this looks like a straightforward missing route, not a congestion problem.
  • The project currently has many Airwires errors, not just this one, so fixing these two pads may clear only one of many unrouted nets.
If +BAT_RAW on those two pads was accidental, then the real fix is on the schematic side:
  • disconnect or rename that net so they are no longer both on +BAT_RAW.
If you want, I can inspect whether ADHESION_1 and ADHESION_2 are supposed to be on +BAT_RAW, and tell you whether to route them or change the net.
Inspect net intent
Check other airwires
Review +BAT_RAW path
Sign up to send

Files

Schematic

Layout

3D View

Project Specification
Design Summary
Status: Approved
Manufacturing target: Prototype
Software / firmware: TBD
Scope
Purpose
This project establishes the approved wireless compute module and integration constraints for a future ESP32-S3 based design. The current revision locks the ESP32-S3-WROOM-1-N16R8 as the required module baseline and records the electrical and RF requirements needed before schematic and PCB implementation.
In scope
  • Approve a single ESP32-S3-WROOM-1 module variant
  • Record minimum memory requirement compliance
  • Document power, boot, programming, and RF integration constraints
  • Define acceptance criteria and checklist for later schematic and layout work
Out of scope
  • Final schematic wiring
  • PCB placement and routing
  • Power supply implementation details beyond interface requirements
  • Peripheral selection and GPIO allocation beyond reserved programming and boot functions
System context
This board will use an ESP32-S3 module as its primary application processor and wireless interface. The project is currently empty, so the module selection does not conflict with existing schematic or layout architecture and can be adopted as the system baseline.
Key interfaces
  • Power input/output: regulated 3.3 V supply to the module
  • Main comms interfaces: 2.4 GHz Wi-Fi and Bluetooth LE via the integrated PCB antenna
  • Debug/programming: native USB D+ and D- or reserved UART0 access
  • Critical external devices: future peripherals must avoid conflicting with boot strapping and programming pins
Block diagram
Diagram



  
    
  
  
    
  














3.3V Power Rail
ESP32-S3-WROOM-1-N16R8
USB or UART Programming
GPIO0 Boot Control
EN or CHIP_PU Reset Network
Integrated PCB Antenna
Application GPIO and Peripherals
Requirements
Functional
  • The design shall use an ESP32-S3-WROOM-1 family module.
  • The approved module shall include at least 8 MB integrated Flash and 8 MB integrated PSRAM.
  • The project shall reserve a valid programming path using native USB or UART.
  • The project shall preserve boot and reset control access for bring-up and firmware download.
  • The schematic baseline shall expose UART0 TX0, UART0 RX0, EN, and BOOT on a dedicated 4-pin programming header.
  • The schematic shall provide a dedicated switched payload output using a low-side N-channel MOSFET and a 2-pin payload connector.
Electrical
  • Input power to module domain: 3.3 V regulated rail
  • Key rails: 3.3 V and GND
  • Module enable: EN or CHIP_PU pulled up to 3.3 V with 10k and filtered with 100 nF to GND
  • Boot mode: GPIO0 shall be HIGH for normal boot and accessible for LOW assertion during download mode
  • Critical interfaces: native USB D+ and D- or UART0 programming path, plus reserved GPIO for application use
  • Local decoupling: provide at least 100 nF near the module supply input in the future schematic
  • Programming header baseline mapping: J1 Pin 1 = TX0, Pin 2 = RX0, Pin 3 = EN, Pin 4 = BOOT
  • Payload power interface baseline: J4 Pin 1 = +BAT_RAW, J4 Pin 2 = 15W_PAYLOAD switched return
  • Payload switch gate drive baseline: U1 IO4 -> R9 100R -> Q1 gate, with R10 10k from gate to GND
Mechanical / environmental
  • Module package baseline: SMD RF module, approximately 25.5 mm x 18.0 mm
  • Layout requirement: place the module at a board edge to support the integrated antenna radiation pattern
  • RF keepout: no copper, traces, planes, or components in the antenna keepout region
  • Antenna exclusion baseline: reserve approximately 12 mm x 6 mm of all-layer keep-out at the antenna-facing board edge until final placement refines the exact zone
  • Operating conditions: not yet defined in this revision
Key constraints
  • Approved module variant is fixed to ESP32-S3-WROOM-1-N16R8 for subsequent design work
  • Memory floor is fixed at 8 MB Flash minimum and 8 MB PSRAM minimum
  • Use the integrated antenna variant only
  • Keep noisy switching circuits and high current loops away from the antenna end of the module
  • Maintain ground continuity under the module body except where excluded by the antenna keepout
  • Do not heavily load or repurpose boot strapping pins during reset
Dependencies and risks
Dependencies
  • Future power subsystem providing a stable 3.3 V rail
  • Future programming connector or USB implementation
  • Future mechanical outline that permits board-edge antenna placement
Key risks
  • Violation of antenna keepout will degrade RF performance
  • Incorrect handling of GPIO0 or EN or CHIP_PU can prevent boot or programming
  • Future peripheral assignment could accidentally consume reserved programming or strapping pins
Validation
Success criteria
  • The selected module is clearly documented as ESP32-S3-WROOM-1-N16R8
  • The selected module meets or exceeds 8 MB Flash and 8 MB PSRAM
  • Project metadata records power, boot, programming, RF, and I/O constraints
  • A documented checklist exists for future schematic and PCB integration
Planned checks
  • Confirm module memory configuration before schematic capture
  • Verify EN or CHIP_PU and GPIO0 support the required boot states in the future schematic
  • Verify native USB or UART programming access remains available during integration
  • Verify antenna keepout and board-edge placement during future PCB layout
  • Verify the dedicated 4-pin header remains accessible from a board edge during PCB placement
Release-facing notes
Expected deliverables
  • Approved module selection baseline
  • Project metadata for constraints
  • Specification and design notes for follow-on schematic and layout work
Special release notes
  • Do not substitute the approved module with a lower-memory ESP32-S3-WROOM-1 variant
  • Preserve access to programming and reset-related signals in future revisions
  • Respect antenna keepout and board-edge placement in all future PCB work
Change notes / open questions
Changes in this revision
  • Approved ESP32-S3-WROOM-1-N16R8 as the module baseline
  • Recorded power, boot, programming, RF, and GPIO reservation constraints
  • Added validation checklist for later schematic and PCB integration
  • Added the dedicated 4-pin programming header mapping and the initial antenna keep-out baseline dimension
  • Added the 15W payload low-side switch using Q1 CSD18532Q5B, J4 payload connector, R9 gate resistor, and R10 gate pull-down
Open questions
  • Final peripheral set and GPIO mapping are still pending
  • Final power source and connector implementation are still pending
Camera And Optical Flow Expansion Implemented
Preserved reserved pins
  • The following ESP32-S3 pins remain unaffected by this integration: TXD0, RXD0, EN, IO0, IO4, IO1, IO2, IO3, and IO5 through IO16
OV2640 camera interface
  • FPC1 is a 24-pin 0.5 mm FPC connector assigned to the OV2640 DVP camera interface
  • SCCB bus mapping: IO17 = CAM_SIOD, IO18 = CAM_SIOC with 4.7k pull-ups to 3V3
  • Timing mapping: IO19 = CAM_XCLK, IO20 = CAM_PCLK, IO21 = CAM_VSYNC, IO47 = CAM_HREF
  • Data mapping: IO48 = CAM_D0, IO45 = CAM_D1, IO46 = CAM_D2, IO35 = CAM_D3, IO36 = CAM_D4, IO37 = CAM_D5, IO38 = CAM_D6, IO39 = CAM_D7
  • Camera control mapping: IO40 = CAM_RESETB, IO41 = CAM_PWDN
Optical flow sensor interface
  • U3 is the SPI optical-flow subsystem placeholder used because the exact PMW3901 library entry is not yet available
  • A dedicated SPI bus is reserved for optical flow and kept separate from reserved pins and existing buses
  • SPI clock mapping: IO42 = FLOW_SPI_SCK
  • Additional reserved optical-flow nets: FLOW_SPI_MOSI, FLOW_SPI_MISO, FLOW_SPI_CS, FLOW_MOTION, and FLOW_RESET
Constraint review
  • Camera and optical-flow integration uses only GPIOs outside the reserved set
  • Existing programming, payload, adhesion, and motor-control buses remain unchanged
  • SCCB pull-ups are added on the camera control bus to 3V3
Motor Driver Expansion Implemented
Motor output headers
  • Six dedicated 2-pin 2.54 mm motor headers were added for the three dual DRV8833 drivers
  • J5 maps to IC2 bridge A: P1 = DRIVER2_MOTOR_A_P, P2 = DRIVER2_MOTOR_A_N
  • J6 maps to IC2 bridge B: P1 = DRIVER2_MOTOR_B_P, P2 = DRIVER2_MOTOR_B_N
  • J7 maps to IC3 bridge A: P1 = DRIVER3_MOTOR_A_P, P2 = DRIVER3_MOTOR_A_N
  • J8 maps to IC3 bridge B: P1 = DRIVER3_MOTOR_B_P, P2 = DRIVER3_MOTOR_B_N
  • J9 maps to IC4 bridge A: P1 = DRIVER4_MOTOR_A_P, P2 = DRIVER4_MOTOR_A_N
  • J10 maps to IC4 bridge B: P1 = DRIVER4_MOTOR_B_P, P2 = DRIVER4_MOTOR_B_N
ESP32-S3 control pin assignment
  • Reserved pins preserved and not reused for motor control: TXD0, RXD0, EN, IO0, and IO4
  • PWM-capable GPIO assignments implemented:
    • IO5 -> IC2 AIN1
    • IO6 -> IC2 AIN2
    • IO7 -> IC2 BIN1
    • IO8 -> IC2 BIN2
    • IO9 -> IC3 AIN1
    • IO10 -> IC3 AIN2
    • IO11 -> IC3 BIN1
    • IO12 -> IC3 BIN2
    • IO13 -> IC4 AIN1
    • IO14 -> IC4 AIN2
    • IO15 -> IC4 BIN1
    • IO16 -> IC4 BIN2
Review summary
  • All six requested motor headers are present and wired to the three DRV8833 devices
  • All twelve requested DRV8833 control inputs are wired to ESP32-S3 GPIOs chosen from the allowed PWM-capable pool
  • Programming and reserved control nets remain isolated from the motor-control assignment set
Adhesion Output Expansion Implemented
Adhesion connector mapping
  • Three dedicated 2-pin adhesion headers were added and labeled ADHESION_1, ADHESION_2, and ADHESION_3
  • ADHESION_1: pin 1 = +BAT_RAW, pin 2 = ADHESION_1_SW
  • ADHESION_2: pin 1 = +BAT_RAW, pin 2 = ADHESION_2_SW
  • ADHESION_3: pin 1 = +BAT_RAW, pin 2 = ADHESION_3_SW
Adhesion switch implementation
  • Q2, Q3, and Q4 are AO3400 N-channel MOSFET low-side switches
  • Q2 source -> GND, gate -> IO1 through net ADHESION_1_CTRL, drain -> ADHESION_1_SW
  • Q3 source -> GND, gate -> IO2 through net ADHESION_2_CTRL, drain -> ADHESION_2_SW
  • Q4 source -> GND, gate -> IO3 through net ADHESION_3_CTRL, drain -> ADHESION_3_SW
  • R11, R12, and R13 are 10k gate pull-down resistors from each gate net to GND
GPIO reservation review
  • Reserved programming and boot pins remain unaffected: TXD0, RXD0, EN, IO0, and IO4
  • Motor-control pins IO5 through IO16 remain dedicated to the three DRV8833 drivers
  • Adhesion outputs use IO1, IO2, and IO3, which are outside the reserved and motor-control sets
Connector Pinout And Load Notes
Programming header
  • J1 pin 1 = UART0_TX0
  • J1 pin 2 = UART0_RX0
  • J1 pin 3 = ESP_EN
  • J1 pin 4 = ESP_BOOT
  • Expected load current: logic and control only, not intended as a power-delivery header
Payload header
  • J4 pin 1 = +BAT_RAW
  • J4 pin 2 = 15W_PAYLOAD switched low-side return
  • Expected load current baseline: battery-path rules and routing baseline are sized for up to 5 A on the +BAT_RAW path
Motor headers
  • J5 through J10 pinout is defined in the motor output header mapping above
  • Expected motor load current per header: TBD pending final motor selection and full DRV8833 operating-limit review
Adhesion headers
  • ADHESION_1 pin 1 = +BAT_RAW, pin 2 = ADHESION_1_SW
  • ADHESION_2 pin 1 = +BAT_RAW, pin 2 = ADHESION_2_SW
  • ADHESION_3 pin 1 = +BAT_RAW, pin 2 = ADHESION_3_SW
  • Expected adhesion load current per header: TBD pending final adhesion-load definition and current budget allocation

  • Design Summary

  • Scope

  • System context

  • Requirements

  • Functional

  • Electrical

  • Mechanical / environmental

  • Key constraints

  • Dependencies and risks

  • Validation

  • Release-facing notes

  • Change notes / open questions

  • Camera And Optical Flow Expansion Implemented

  • Preserved reserved pins

  • OV2640 camera interface

  • Optical flow sensor interface

  • Constraint review

  • Motor Driver Expansion Implemented

  • Motor output headers

  • ESP32-S3 control pin assignment

  • Review summary

  • Adhesion Output Expansion Implemented

  • Adhesion connector mapping

  • Adhesion switch implementation

  • GPIO reservation review

  • Connector Pinout And Load Notes

  • Programming header

  • Payload header

  • Motor headers

  • Adhesion headers