Platform migrations

​

Define behavioral equivalence first

• the source and target MCU, package, board, and board revision;
• the SDK, HAL, RTOS, compiler, linker, and build configuration on each side;
• the public firmware interfaces that must remain compatible;
• required peripherals, pins, clocks, DMA channels, interrupts, and power states;
• timing, throughput, memory, and power budgets;
• boot, flash, debug, and log paths;
• host tests and on-target observations that prove equivalence.

Migrate the motor-control example from KIT_A2G_TC375_LITE to
KIT_A3G_TC4D7_LITE. Preserve the control-loop API and 10 kHz update rate.
Use only pins routed to the target kit headers, retain serial diagnostics,
and verify PWM timing and fault input behavior on the target board.

​

Prepare both sides

​

Compare source and target constraints

Compare the source UART implementation with the selected target platform.
Identify differences in clocking, reset, register layout, FIFO behavior,
interrupts, DMA requests, pin routing, and error handling. Cite the applicable
source and target documents and list unresolved board-level assumptions.
Do not edit the project.

Compare @sch:component:U1 and @sch:net:CAN_TX with the proposed target pin.
Confirm the transceiver voltage domain and connector path before finalizing
the pin assignment.

​

Create a migration plan

​

Use Plan mode

/plan

1. source and target facts with unresolved assumptions;
2. the selected pins and proof of board accessibility;
3. build-system, startup, linker, and configuration changes;
4. a module-by-module implementation order;
5. tests at each stable boundary;
6. runtime log or measurement points;
7. flash, debug, and rollback requirements;
8. final behavioral-equivalence checks.

Plan this migration without changing project files. Separate source facts,
target facts, and assumptions. Keep the application-facing driver API stable
where practical. Order the work so each peripheral module builds and has an
isolated test before the next module moves.

​

Review the plan before execution

• The target part, package, board, and revision are exact.
• Every proposed pin is reachable and electrically compatible.
• Vendor-generated and hand-maintained code boundaries are explicit.
• The source baseline and target pass criteria use comparable workloads.
• Build and flash commands refer to the target, not the source.
• Destructive setup or generated-file replacement requires review.
• Each implementation step leaves the project in a buildable or testable state.
• A failure has a rollback or diagnosis path.

​

Implement module by module

​

Verify the target against the baseline

1. Run unchanged host tests where the platform boundary permits it.
2. Build the intended target configuration and identify its artifact.
3. Flash only the selected board and capture early runtime output.
4. Exercise the same inputs and operating conditions used for the source baseline.
5. Compare protocol traffic, timing, output values, memory use, and power where they are requirements.
6. Record accepted differences and the hardware or documentation evidence that justifies them.

Build and flash the target image. Capture PWM and the fault input with the
logic analyzer for the same five-second workload used on the source board.
Compare frequency, duty-cycle range, startup ordering, and fault latency.
Report any difference outside the migration plan's tolerances.

​

Respect platform-specific boundaries

• Board skills provide fixed pinout and tooling context; they do not guarantee every board assembly, silicon step, probe, or toolchain combination.
• Different platform families use different compilers, loaders, debuggers, and startup conventions.
• Embedder does not provide vendor SDKs, compilers, flashers, debuggers, virtual platforms, licenses, or confidential documents.
• There is no automatic platform-diff or code-porting engine. The result depends on the reviewed plan, available source material, project tests, and target evidence.