Define what the new target must preserve before porting code: interfaces, timing, startup behavior, peripheral functions, and resource limits.
For a change of real-time operating system, see RTOS migrations, including the FreeRTOS-to-Zephyr example.
Identify both targets
Record the source and destination MCU, package, board revision, SDK, toolchain, and build configuration. Add target documentation and schematics when the catalog does not cover the board.
Capture the source baseline
Run the existing tests and selected hardware checks before changing the port. Save the outputs the new target must match.
Use the same workload and tolerances on both boards. Identify accepted differences explicitly.
Compare hardware constraints
Run /plan and ask Embedder to compare clocks, reset sequences, registers, pin routing, interrupts, DMA, memory layout, startup, and tools.
Check package and board routing, not only the MCU’s alternate-function table. A valid peripheral pin may be reserved or inaccessible on the board.
Review an ordered plan
The plan should establish the target build first, then bring up observation, port one service at a time, and verify its consumers. Require affected files, generated-code boundaries, tests, and a recovery path for failed bring-up.
Approve the plan to begin implementation in Act mode.
Port one module at a time
- Produce the smallest target image with the correct startup and linker setup.
- Establish UART, RTT, or another observation path.
- Move one clock, GPIO, transport, or timing service.
- Run its focused tests and target check.
- Continue to dependent modules only after the lower layer works.
Do not copy register values across families without checking the destination reference.
Prepare an ADS/iLLD project for CLI builds
For an AURIX Development Studio project, use the AURIX ADS and Flasher guide to prepare CLI builds on Windows. It covers ADS, extracted iLLD, CPU/linker prerequisites, generated-file replacement, preservation of existing build outputs, and the separate flasher setup.
This setup is optional. Record another existing AURIX build workflow directly in EMBEDDER.md when it already fits the project.
Verify equivalent behavior
Use Debug mode when state inspection is needed. Preserve a fault before reset or reprogramming.
Update EMBEDDER.md with the destination commands and record any behavior still unverified. See Supported hardware for setup references. Last modified on September 18, 2026
