# Arhan - I’m recreating the Adafruit Feather RP2...

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1539962907935244359
Started: 2026-08-20T11:42:48.845000+00:00
Last activity: 2026-08-21T00:17:56.300000+00:00

## Arhan — 2026-08-20T11:42:48.379000+00:00

I’m recreating the Adafruit Feather RP2040 USB Host board in TSCircuit from the official Eagle reference.

Placement, netlist, TypeScript, and shorts checks pass. After adding the full support-net connectivity, autorouting fails with:

```text
TypeError: undefined is not an object (evaluating 'connectedPort.x')
```

PCB traces remain unrouted afterward.

Could this be a real TSCircuit autorouter issue, or is it more likely caused by my custom footprints/routing model? Worth minimizing into a repro?

## Rishabh — 2026-08-20T12:32:00.080000+00:00

I don't think it's an autorouter error, it's a type error

## Rishabh — 2026-08-20T12:32:38.434000+00:00

It should be simple to figure out the type you are using incorrectly

## Arhan — 2026-08-20T14:51:10.569000+00:00

I traced the TypeError to the USB-C component having missing PCB ports after its standard footprint fetch failed. Is it expected behavior for an incomplete/missing footprint to crash with `connectedPort.x`?

## Seve — 2026-08-20T15:55:17.647000+00:00

If the fetch failed then autorouting should be blocked

## Arhan — 2026-08-20T16:03:22.277000+00:00

I verified this in `core`.

The existing USB-C fetch-failure test confirms that a failed standard-footprint fetch can leave the connector with logical ports but zero PCB pads:

```ts
expect(circuit.db.pcb_smtpad.list()).toHaveLength(0)
```

From:

`tests/repros/repro-usbc-parts-engine-failure-empty-schematic.test.tsx`

In `lib/utils/autorouting/getSimpleRouteJsonFromCircuitJson.ts`, the autorouting path maps source ports to PCB ports and filters only `null` values:

```ts
const connectedPcbPorts = trace.connected_source_port_ids
  .map((sourcePortId) => db.pcb_port.getWhere({ source_port_id: sourcePortId }))
  .filter((pcbPort) => pcbPort !== null)
```

It then accesses:

```ts
for (const connectedPort of connectedPcbPorts) {
  if (connectedPort.x === undefined || connectedPort.y === undefined) {
    // ...
  }
}
```

When the PCB port is missing, the property access itself throws:

```text
TypeError: undefined is not an object (evaluating 'connectedPort.x')
```

Would a failed footprint fetch be expected to block autorouting with a clear error, rather than allowing autorouting to crash?

## Seve — 2026-08-21T00:17:56.300000+00:00

block routing, show error