Updating Two MCUs in One Product: Define Compatible Intermediate Firmware States
When only one MCU has advanced, the product must enter a deliberately supported intermediate state or a defined restricted state. Do not let “both images downloaded” stand in for a coordinated update. Specify which version pairs can communicate, which functions remain available, and how the next transition proceeds after either processor resets.
This article proposes an application-level coordination design for two MCUs with separate nonvolatile storage and a communication link. It draws architectural boundaries from RFC 9019 and RFC 9124, both informational IETF documents. It does not claim that either RFC supplies a ready-made atomic-update protocol, nor that the example provides a safety certification. No target firmware or update transaction was executed for this article.
1. Enumerate the four version pairs
Let A be a supervisor and B an I/O coprocessor. Each has an old and a new application image. The product can encounter A1/B1, A1/B2, A2/B1, and A2/B2, even when the intended endpoints are only the first and last pairs. Reboots, confirmation failures, replacements, and interrupted downloads make the other combinations relevant.
RFC 9019’s separate-memory multi-CPU case explicitly recognizes that each CPU has its own update responsibility and that atomic coordination is challenging. Treat this as a reason to design intermediate behavior, not as permission to assume a central updater can commit both flash devices simultaneously.
The following is an expressly hypothetical compatibility contract. B2 retains the old P1 command format while adding P2; A2 requires P2 for normal operation.
| Supervisor | B1 | B2 |
|---|---|---|
| A1 | Normal operation using P1 | Supported bridge state using P1; P2 features disabled |
| A2 | Restricted operation; normal I/O commands inhibited; recovery/status channel required | Normal operation using P2 after successful handshake |
Assign test cases and observable behavior to every cell, including the restricted one. “Unsupported” is not enough: state whether the product rejects commands, reports a maintenance condition, or invokes an independent recovery route. Define that behavior against the product’s hazard and availability requirements.
2. Derive the order from the matrix
The supported forward route in this example is A1/B1 to A1/B2 to A2/B2. Update B first, establish the bridge state’s behavior, and only then permit A to advance. The route follows compatibility; it is not a general rule that a peripheral always updates first.
The reverse route matters too. Returning from A2/B2 through A1/B2 is supported, while independently reverting B first would create A2/B1. Consequently, B’s local confirmation and automatic-revert policy must be coordinated with A’s transition. If B may still autonomously revert after A advances, the design must either tolerate that pair or prevent the transition until the risk is resolved.
Enumerate what each bootloader can do without consulting its peer. A central application cannot promise a rollback order that a local bootloader ignores during reset. Where no compatible route exists, introduce a qualified bridge release, redesign the interface contract, or perform the migration in a restricted maintenance mode.
3. Bind the package to component identities
RFC 9124’s dependency model represents required manifests using unambiguous identity, such as a digest. Its component-update discussion also covers multiple microcontrollers and different payload destinations. Use those concepts to prevent an update coordinator from treating two similarly named binaries as a coherent release.
For the proposed product, define a release transaction with the intended A and B artifact identities, allowed starting pairs, required bridge behavior, and final compatibility contract. Authenticate the metadata and payloads through the existing update trust design. A human-readable release number is useful for operators but insufficient for deciding that the correct partner image is installed.
Check board variants and independently replaced modules. A replacement B may have an older bootloader, a different partition limit, or a different application capability. Compare its reported identity with the supported matrix before initiating the coordinated operation.
4. Make the compatibility handshake explicit
On each boot or peer reconnection, exchange enough information to select a permitted operating contract:
- Component identity, application artifact identity, and relevant bootloader capability
- Supported protocol versions or capability sets, including required command semantics
- Current local update state: staged, running candidate, confirmed, or recovery
- The coordinated transaction identity and a fresh session identity
- A declared readiness result for the selected pair, including any restricted functions
These fields are a design proposal, not a standardized wire format. Validate sizes and values, bind replies to the current session, and reject stale readiness from a previous boot. If the communication link is in the threat model, protect authenticity and freshness appropriately; version negotiation alone is not authentication.
Require an explicit agreement before issuing commands whose meaning changed. B2 supporting both P1 and P2 is only useful if it can tell which contract A selected. A numeric version comparison such as “peer is newer” cannot establish compatible units, command layouts, or failure semantics.
5. Journal local facts and reconcile after reset
Choose one coordinator for the transaction. Persist only facts that the local MCU can establish: candidate artifact verified, local boot selected, candidate started, or local confirmation complete. Separately record the most recently observed peer state, with its session identity. Do not write “both committed” merely because a message was sent.
After reset, query the actual peer and reconcile it with the local durable record. Duplicate stage or status messages should have a defined idempotent response. A repeated request must not erase a successfully staged candidate solely because the sender did not receive the previous acknowledgement.
Include timeout ownership. If A cannot contact B, define whether it waits, offers restricted service, or enters recovery. Limit retries and report the known local state plus the unknown peer state. Avoid replacing uncertainty with a fabricated success or a destructive restart loop.
6. Test the transition edges, not only the endpoints
| Interruption point | Required observation |
|---|---|
| B is staged but has not booted | A1/B1 remains usable or the documented maintenance state is retained |
| B2 starts and A remains old | A1/B2 selects P1 correctly and exposes only permitted functions |
| A2 starts before final confirmation | The actual local revert choices remain compatible with the peer |
| Peer-link failure during readiness exchange | No stale readiness enables an incompatible command contract |
| One MCU resets after the coordinator records progress | State reconciliation reflects the running images, not the last attempted command |
| An old replacement module is connected | The unsupported pair is detected before normal operation is enabled |
Run the matrix on recoverable development units with outputs made safe. Capture image identities from both processors and verify an end-to-end application transaction. Separate image-transfer success, local boot success, and pair readiness in the test report.
7. A hypothetical changed command unit
Suppose P2 changes a command’s scale while retaining the same numeric message identifier. If A2 talks to B1 without negotiation, the bytes may be accepted but mean the wrong physical request. The restricted A2/B1 cell prevents normal commands until a compatible contract is established; simply checking that the link is alive would miss the defect.
Qualification should include values that distinguish the old and new scales, boundary values, and rejected commands. Release only when every reachable pair has a tested behavior and every transition has an owner. A coordinated update is complete when the intended pair is authenticated, running, confirmed as required, and operating under the agreed protocol contract.
