STM32H5 Field Service: Choose Debug Reopening or Destructive Regression Before Provisioning
“We can unlock it for service” is an incomplete STM32H5 requirement. An operation that returns a device to OPEN can also erase the firmware and RAM needed to explain the failure. Decide whether the service goal is temporary diagnostic access or destructive restoration before manufacturing credentials are provisioned.
This discussion scopes the H563/H573-style H5 lifecycle services described in AN6008 Rev 6 and ST's Debug Authentication guide. It does not transfer the H503 credential-storage model to these devices. No authentication, provisioning or lifecycle transition was executed.
Password authentication does not mean nondestructive debug
For this H5 scope, AN6008 Rev 6 connects the authentication method to TrustZone configuration. With TrustZone disabled, the password method supports full regression only. With TrustZone enabled, the certificate method supports authorized regression and debug-reopening services.
This is an architectural distinction, not a choice between two interchangeable login screens. A repair requirement to inspect an intact secured unit cannot be satisfied merely by saving a password for a TrustZone-disabled configuration. Its supported authenticated service returns the device through full regression.
Provisioning also has a compatibility constraint. AN6008 requires credentials to be provisioned in the PROVISIONING state and warns that supplying a password hash with TrustZone enabled, or a certificate-root public-key hash with TrustZone disabled, can permanently lock an H5. The manufacturing specification must pair the intended TZEN setting with the correct credential format and authorized services.
Describe regression by its destructive effects
Full regression changes the product state to OPEN. The note lists erasure of user flash, OBK, SRAM and backup RAM, along with changes to epochs, protections, boot settings and cryptographic key registers. A request is rejected when the device's configured permissions do not authorize it. The service is unavailable in OPEN and LOCKED.
A successful full regression is consequently not a successful preservation of fault evidence. A crash record in SRAM, a field configuration in user flash and a service credential in erased storage cannot be assumed to survive. If the repair process requires those records, define an authorized acquisition path before any destructive operation.
The ST H5 Debug Authentication guide also distinguishes partial regression and debug reopening under certificate authentication. Those names must remain separate in service instructions. A generic “unlock” button obscures both the requested access and the resulting lifecycle state.
Reopening has a context and a lifetime
Certificate-based reopening does not mean unrestricted debug from the first instruction onward. The request includes a security context and HDP level, and access depends on the device reaching an allowed execution context.
AN6008 illustrates a request for nonsecure debug at HDP level 3. The device must progress through its secure boot stages and enter the matching nonsecure context before that connection becomes available. An authorized service request can therefore coexist with an unavailable debug connection while execution is still earlier in boot. Diagnose the requested context before declaring the credential invalid.
The note also distinguishes reset from power cycling. Reopening persists across reset but is canceled by removing and restoring power; the debug state then returns to that driven by the product state. A fixture that resets the CPU and one that power-cycles the board do not test the same persistence boundary.
LOCKED is a separate limit: the documented reopening service is unavailable there. A service plan must not promise recovery through credentials after choosing a lifecycle state that excludes the service.
Include silicon limitations in the service contract
The supported authentication scheme is only one part of availability. ES0565 Rev 8 gives different applicability for three relevant limitations. EDATA-enabled regression (2.2.10) and hardware-controlled IWDG interaction (2.2.15) affect revisions A/Z and are marked absent on X/W. The hardware-controlled WWDG interaction (2.2.16) affects all four listed revisions: A/Z/X/W. Read each entry and its workaround separately for the actual silicon; a newer revision does not remove the documented WWDG constraint.
Do not reduce that check to whether a debugger connects to a development board in OPEN state. The service route has to be qualified from the intended production lifecycle state, with the production boot and watchdog configuration. Keep the provisioned permission set and tested service request in the qualification record without exposing private credentials in ordinary logs.
Turn repair scenarios into distinct acceptance cases
An intact-data diagnosis case should request only the authorized reopening context and verify that the required evidence remains available. A restoration case can explicitly accept full regression's erasure and verify the resulting OPEN state before reinstallation. These are different acceptance cases even if a technician starts both from the same tool.
For reopening, observe the allowed execution context before and after reset, then after a genuine power cycle. For regression, use disposable fixtures and verify the documented erased regions and lifecycle outcome. Exercise a disallowed service request through the approved test procedure and require a refusal rather than silently substituting a more destructive service.
These are proposed qualification steps, not reported results. The useful deliverable is a service decision table with intended state, TrustZone setting, credential method, permitted action, erase consequences and power-cycle behavior. It lets manufacturing and field service agree on what access will actually remain possible after shipment.
