AM263P4: How to Configure and Verify Lockstep Mode on LP-AM263P

1. Configuring Both R5F Core Pairs in Lockstep Mode

Lockstep mode is typically configured at boot time and cannot be changed at runtime:

• SysConfig (CCS/MCU+ SDK): In your project's .syscfg file, select the R5F Cluster configuration and set the operating mode to "Lockstep" for each cluster (Cluster 0 and Cluster 1).
• Boot Configuration: The device's DEVSTAT/boot mode pins or ROM boot configuration determines whether clusters start in lockstep or split (dual-core) mode. For development, SysConfig and the bootloader handle this.
• When lockstep is enabled, Core 1 in each cluster becomes the shadow core — it executes the same instruction stream as Core 0 but its outputs are compared rather than driven externally.

2. Loading and Running Different Applications on Two Lockstep Clusters

Each lockstep cluster appears as a single logical core to the debugger and bootloader:

• In CCS: You will see two R5F targets (one per cluster) when lockstep is enabled. Load Application A to Cluster 0 and Application B to Cluster 1 independently.
• Via SBL (Secondary Bootloader): Configure your multicore image (.appimage) to contain two application binaries — one targeted at R5FSS0 and one at R5FSS1. The SBL loads and starts each cluster independently.
• Both clusters run concurrently with independent program counters, memory maps, and interrupt configurations.

3. Verifying Correct Lockstep Execution

Lockstep verification is handled entirely in hardware — you do not need software-level result comparison:

• The hardware comparator checks outputs from both cores every clock cycle (bus transactions, register writes, control signals).
• If outputs match, execution proceeds transparently. The system behaves as a single-core cluster from the software perspective.
• There is no software API to "read" the shadow core's results — the comparison is implicit and continuous.

4. Detecting Lockstep Mismatches

When a mismatch occurs between the primary and shadow cores:

• The R5F subsystem generates a lockstep compare error event.
• This event is routed to the ESM (Error Signaling Module).
• The ESM can be configured to:
  • Trigger an interrupt (for software handling/logging)
  • Assert an external error pin (nERROR) for system-level response
  • Trigger a device reset (for safety-critical applications)

5. Fault Status Registers and Diagnostic Mechanisms

6. Example Projects and Validation

• The MCU+ SDK for AM263Px should include an SDL (Safety Diagnostic Library) with lockstep-related examples, including ESM configuration and STC (Self-Test Controller) usage.
• Look for examples under: <SDK_INSTALL>/examples/sdl/ — specifically STC and ESM examples.
• The AM263Px Technical Reference Manual (TRM) documents the R5FSS lockstep architecture, ESM event mappings, and STC registers.

...Please refer to the AM263P4x TRM se

Anburaja A said:

1. Clarification on Lockstep Configuration in SysConfig

You mentioned that Lockstep mode can be configured through SysConfig by selecting the R5F Cluster operating mode as "Lockstep".

Could you please provide more specific guidance on the following:

• In SysConfig, under which module or configuration section is the R5F Cluster operating mode configured?

• What exact setting or option should be selected to enable Lockstep mode for R5FSS0 and R5FSS1?

• After enabling Lockstep mode in SysConfig and generating the project files, which generated file(s) should I inspect to verify that the configuration has been applied correctly?

• Does SysConfig generate any specific macros, configuration structures, linker settings, or boot configuration parameters that indicate the cluster is configured for Lockstep operation?

• Could you provide an example of the generated configuration or code snippet that confirms Lockstep mode has been enabled?

Anburaja A said:

2. How to Confirm That a Cluster Is Actually Running in Lockstep Mode

After building and loading the application, I would like to verify that the hardware is truly operating in Lockstep mode.

Could you please clarify:

• Is there a register, status bit, DEVSTAT field, or R5FSS configuration register that explicitly indicates whether the cluster is running in Lockstep mode or Split mode?

• Can this be verified through CCS Register View or Memory Browser? If yes, which register should be checked?

• When debugging in CCS, what should I expect to see when a cluster is configured in Lockstep mode?

• Should only one debugger target appear for each R5F cluster, or is there another recommended method to confirm Lockstep operation?

• Is there any software API, SDL API, diagnostic test, or boot log message that can be used to confirm that Lockstep mode is active?

Refer to AM263P4x register addendum for the respective register

Anburaja A said:

3. Clarification on Lockstep Validation Using SDK Examples

I am currently reviewing the following SDK example:

mcu_plus_sdk_am263px_10_00_00_26/examples/sdl/stc/stc_mcu/am263px-cc/

which contains:

• r5fss0-0_nortos

• r5fss1-0_nortos

• system_nortos

Could you please clarify:

• How does this example validate or demonstrate Lockstep functionality?

• Does the STC example require the R5F cluster to already be configured in Lockstep mode?

• If the example executes successfully, how can I determine whether it was running in Lockstep mode versus Split mode?

• Which status registers, ESM events, fault flags, or diagnostic outputs should be checked as proof that the Lockstep comparator is active?

• Is there a recommended fault-injection procedure to intentionally trigger a Lockstep compare error and verify the ESM reporting path?

• Are there any dedicated Lockstep validation examples available in the MCU+ SDK in addition to the STC example?

My objective is to understand both the configuration flow and the recommended method to conclusively verify that the Lockstep hardware mechanism is enabled and functioning correctly on R5FSS0 and R5FSS1.

Refer to this document: software-dl.ti.com/.../SDL_STC_PAGE.html