Bring-up of a safety-critical ADAS ECU prototype

The problem

A new ADAS ECU prototype had to boot, pass electrical validation and run AUTOSAR software on a compressed schedule. The hardware existed, but the software side was a pile of unknowns: an unfamiliar co-processor configuration, a boot chain nobody had fully traced on this revision, and multiple teams (hardware, systems, integration) whose assumptions didn’t line up.

If the ECU didn’t come alive reliably early, every downstream team — HIL, calibration, systems testing — had no target to test against.

Constraints

• Silicon was new to the team. Aurix TriCore with a safety co-processor, and the vendor reference software didn’t match the board’s actual wiring.
• No room to guess. Electrical faults and software faults look identical from a debugger. Validating hardware first was non-negotiable.
• Safety process applies from day one. Even prototype code had to be traceable and MISRA-clean enough to survive later ASIL D review rather than be thrown away.

What I did

Split the bring-up into layers and prove each one before moving on. Power rails and clock first, then the debug interface, then the boot chain, then the OS. Every step got a physical checkpoint with a scope or logic analyser — “the rail is up” is a measurement, not an opinion.

Configured the AUTOSAR OS for a multi-core safety target. Task scheduling, partitioning and peripheral setup on the co-processor, tuned so that timing-critical tasks met their deadlines without starving diagnostics.

Traced the boot chain end to end, including low-level Assembly startup code, and fixed defects in startup and diagnostics that had been masked by earlier assumptions.

Ran integration with the communication stacks — CAN, LIN and Ethernet — so the software team could exercise real traffic rather than stubs.

Trade-offs

• I spent the first days validating hardware instead of writing software. It looks slow on a Gantt chart, but it removed the ambiguity that would otherwise have burned far more time in joint debugging sessions.
• Early AUTOSAR configuration stayed conservative — fewer, larger partitions and a simple scheduling layout — rather than an optimised one. Optimising before the platform was proven would have meant re-doing it anyway.

Outcome

The prototype platform came up cleanly, passed validation, and gave the downstream teams a working target. The power-management component built during this effort was later certified and reused across multiple customer projects.

What I’d do differently

I’d document the boot-chain trace from the first day, not the second week. Six months later it became the onboarding reference for the next engineer, and it should have existed before anyone needed it.