Comma.ai Panda Board
Thought for 5 sec
Use TI TCAN3404-Q1 for each of the three CAN channels.
Why it fits:
- CAN FD: supports data rates up to 8 Mbps
- Automotive qualified: AEC-Q100
- 3.3 V MCU interface: compatible with the STM32H725
- Wide bus fault protection: ±58 V
- Low-power standby mode
- Small VSON package: suitable for the 85 × 50 mm board
Recommended orderable part:
- TCAN3404DRBRQ1
- Package: 8-pin VSON/DRB, 3 × 3 mm
- Quantity: 3
Use one TCAN3404-Q1 per channel, followed by the channel’s common-mode choke and PESD2CAN protection. Verify that the footprint includes the exposed thermal pad and connect it to ground with nearby vias.
Recommand NXP product
Thought for 14 sec
I recommend the NXP TJA1044GT/3 for each CAN channel.
- Automotive AEC-Q100
- CAN FD up to 5 Mbit/s
- Designed for direct use with 3.3 V microcontrollers, including STM32H725
- Standby and wake-up support
- SO8 package, easier to assemble than VSON
- Bus fault protection and excellent automotive EMC performance
Use three TJA1044GT/3 transceivers, one per CAN-FD channel. For improved signal integrity on long or highly branched automotive networks, consider the newer NXP TJA1443 CAN SIC transceiver, but it is larger and requires more support/configuration.
Replace and review
Replace transceivers
Compare NXP options
Check footprint fit
Update BOM cost
Refine this doc
Ask about this doc
Automotive Traceability
Status and intent
Draft, schematic phase. This matrix traces live schematic features to preliminary automotive requirements and planned evidence. It does not claim ISO 26262 compliance, vehicle approval, or ASIL capability. HARA, item definition, ASIL allocation/decomposition, safety goals, technical safety concept, validation independence, and external-lab plans remain explicitly open.
Configuration baseline
- U1: STM32H725ZGT6, official commaai/panda firmware is the primary compatibility target.
- Vehicle input: J2 pin 16 (
VBAT_RAW) through F1, D5, D6 and U5 to 3V3. - CAN1: J2 6/14, U2, FDCAN1 PD0/PD1, STB PG11.
- CAN2: J2 3/11, IC1, FDCAN2 PB5/PB6, STB PB3.
- CAN3: J2 1/9, IC2, FDCAN3 PD12/PD13, STB PD7.
- USB device: J1, D1, PA11/PA12; VBUS monitor PA0 through R3/R4.
- Debug/boot/reset: J3 PA13/PA14/NRST; BOOT0 10 kΩ pull-down R14; NRST 10 kΩ pull-up R15.
Preliminary requirements trace
Table
| ID | Preliminary requirement | Live design trace | Verification evidence / status |
|---|---|---|---|
| PWR-001 | Board shall accept nominal 12 V only through the protected vehicle input path. | J2.16 → F1 → D5; D6 clamps fused node; U5 regulates. | Schematic traced; bench continuity/current-limit test planned. Automotive pulse adequacy open. |
| PWR-002 | 3V3 shall remain within approved MCU/transceiver limits in normal operation. | U5 LM65645SRZTRQ1, L4, C31–C34; 3V3 distributed to U1/U2/IC1/IC2. | Bring-up target 3.20–3.40 V and ≤50 mVpp preliminary; temperature/load limits open. |
| PWR-003 | Reverse battery and vehicle transients shall not create an unsafe output. | D5 SS56 series diode; D6 SMBJ24A TVS; F1 resettable fuse. | Component intent traced. D5/D6 automotive qualification and pulse coordination uncertain; ISO 7637/16750 lab work open. |
| CAN-001 | Three independent CAN-FD channels shall map to the specified J2 pins. | CAN1 6/14; CAN2 3/11; CAN3 1/9; D2–D4 and L1/FL1/FL2 in each pair. | Netlist verified; external loopback/bus tests planned for all channels. |
| CAN-002 | CAN transmitters shall enter a non-driving standby state during reset/startup/fault handling. | U2 STB=PG11, IC1 STB=PB3, IC2 STB=PD7; SHDN tied low. | Firmware starter initializes STB high before enabling CAN. Hardware reset-state behavior and fault injection evidence open. |
| CAN-003 | Termination shall be configured only where required by network topology. | R5/R6, R7/R8, R9/R10 are 60.4 Ω split pairs; C25/C26/C27 center capacitors; role says DNP/assembly-selectable. | Assembly-option control and production inspection procedure open; resistance check in bring-up plan. |
| CAN-004 | Received commands shall be validated before affecting safety-relevant behavior. | Implemented in primary panda-compatible firmware, not by passive schematic. | Open: protocol safety requirements, authentication/counters where applicable, timeout/range/state validation, HARA/ASIL allocation, software verification. |
| CAN-005 | Corruption, overflow, bus-off, and cross-channel faults shall be detected, contained, logged, and recovered per approved policy. | Three FDCAN instances; separate transceivers/STB; shared MCU and 10 KiB FDCAN message RAM. | Firmware and stress/fault tests open. Shared-resource interference analysis open. |
| USB-001 | USB shall operate as a full-speed device without back-powering or disturbing 3V3. | J1, D1, PA11/PA12, VDD50USB from VBUS, PA0 100 kΩ/100 kΩ VBUS divider. | Enumeration/reconnect/power checks planned; USB compliance lab open. |
| DBG-001 | Development units shall support controlled programming/reset and normal flash boot. | J3 SWDIO PA13, SWCLK PA14, NRST; R14 BOOT0 pull-down; R15 NRST pull-up. | SWD detection/program/reset tests planned. Production debug-access policy open. |
| IND-001 | LEDs shall be treated as diagnostic indicators only, not sole safety evidence. | Active-low PE4 red, PE3 green, PE2 blue through 1 kΩ resistors. | Firmware lamp test planned; human factors and diagnostic semantics open. |
| CON-001 | Connector opens, swaps, shorts, loss of ground, and mis-termination shall not create uncontrolled CAN transmission. | J2 mapping; protected CAN front ends; firmware STB control. | Bench fault tests planned; vehicle harness and short-circuit qualification open. |
| THM-001 | Regulator and protection devices shall remain within thermal limits at all approved loads/temperatures. | U5 rated architecture, D5/F1/D6 input path, output capacitor bank. | Thermal scan planned; worst-case dissipation, enclosure, chamber, and derating analysis open. |
| CFG-001 | Hardware population, firmware, CubeMX/HAL version, and termination state shall be traceable per unit/revision. | Documented component designators and nets. | Open: revision-controlled BOM variants, serialization, production records, signed firmware/release process. |
Safety lifecycle work products still open
- Item definition and vehicle-level operating scenarios.
- HARA, hazard classification, ASIL determination, safety goals, and safe-state definition.
- Functional/technical safety concepts and hardware/software safety requirements.
- FMEDA, diagnostic coverage, dependent-failure/common-cause analysis, freedom-from-interference, and tool qualification strategy.
- Requirements bidirectional trace in an approved lifecycle tool, change/configuration management, reviews, and confirmation measures.
- External EMC, ESD, ISO 7637/16750 transient, environmental, vibration, thermal, CAN conformance, and USB compliance testing.
- Supplier qualification/PPAP evidence and automotive qualification of all parts, explicitly including uncertain D5 and D6 status.
- Vehicle connector/harness pinout approval and application-specific network topology/termination approval.
Change control
Any schematic, pin map, termination population, firmware protocol, or safety-policy change must update this matrix and the FMEA before release. “Test passed” is not equivalent to closure until the result is linked to an approved requirement, method, acceptance criterion, artifact, reviewer, and configuration baseline.
Status and intent
Configuration baseline
Preliminary requirements trace
Safety lifecycle work products still open
Change control
