Bus Fault When Configuring Cross Trigger Matrix on ARM Cortex-M4

ARM Cortex-M4 Cross Trigger Matrix Configuration and Bus Fault Analysis

The ARM Cortex-M4 core, when integrated into a System-on-Chip (SoC) such as the Cypress TII MCU, provides a Cross Trigger Interface (CTI) and Cross Trigger Matrix (CTM) to enable sophisticated debugging and event management capabilities. These features allow developers to route debug events, such as core halts, to peripherals like watchdogs (WDG) for enhanced debugging control. However, configuring the CTI and CTM can lead to unexpected bus faults, particularly when accessing the CTICONTROL register at address 0xE0042000. This issue is exacerbated when the debugger is disconnected, suggesting a nuanced interaction between the debug subsystem, the processor core, and the SoC implementation.

The bus fault occurs specifically when writing to the CTICONTROL register, with the Bus Fault Address Register (BFAR) correctly identifying the faulting address as 0xE0042000. The fault is characterized by the PRECISERR (Precise Bus Fault) and BFARVALID (BFAR Valid) flags being set in the Configurable Fault Status Register (CFSR). Notably, the fault does not occur when the debugger is connected, indicating that the debugger’s presence alters the system’s behavior in a way that masks the underlying issue.

Debugger-Dependent Behavior and SoC Integration Constraints

The root cause of the bus fault lies in the interaction between the ARM Cortex-M4 core, the Cross Trigger Interface, and the specific implementation of the Cypress TII MCU. The CTI and CTM are part of the CoreSight debug architecture, which provides a standardized framework for debugging ARM processors. However, the integration of CoreSight components into an SoC can introduce constraints that are not explicitly documented in the ARM reference manuals.

One such constraint is the requirement to configure the Cross Trigger Matrix from a debugger script immediately after a core reset. This requirement arises because the CTI and CTM registers, particularly those in the External Private Peripheral Bus (PPB) address range (0xE0042000 and above), may not be accessible in certain operational modes or states of the SoC. When the debugger is connected, it typically initializes the debug subsystem, including the CTI and CTM, as part of its connection sequence. This initialization ensures that the registers are accessible and properly configured before the application code attempts to use them.

In the absence of the debugger, the application code attempts to access the CTICONTROL register without the necessary initialization, resulting in a bus fault. This behavior is consistent with the observation that the fault does not occur on other MCUs, such as the STM32F4x series, where the SoC integration may not impose the same constraints.

Debugger Script Initialization and Register Access Timing

To resolve the bus fault issue, the Cross Trigger Matrix must be configured from a debugger script during the debugger’s connection sequence or immediately after a core reset. This approach ensures that the CTI and CTM registers are accessible and properly initialized before the application code attempts to use them. The following steps outline the recommended approach to configuring the Cross Trigger Matrix:

1. Debugger Script Configuration: Create a debugger script that initializes the CTI and CTM registers as part of the debugger’s connection sequence. This script should be executed automatically when the debugger connects to the target or after a core reset. The script should include the necessary writes to the CTICONTROL, CTIINEN, and CTIOUTEN registers to configure the Cross Trigger Matrix as required.

2. Register Access Timing: Ensure that the application code does not attempt to access the CTI and CTM registers until the debugger script has completed its initialization sequence. This can be achieved by adding a delay or synchronization mechanism in the application code to wait for the debugger to complete its initialization.

3. Privileged Mode Access: Verify that the application code accesses the CTI and CTM registers from privileged mode. While the original issue report confirms that the code was already running in privileged mode, it is essential to double-check this aspect to rule out any potential mode-related issues.

4. SoC-Specific Considerations: Consult the SoC manufacturer’s documentation for any additional constraints or requirements related to the CTI and CTM configuration. The Cypress TII MCU may have specific initialization sequences or timing requirements that are not covered in the ARM reference manuals.

By following these steps, developers can ensure that the Cross Trigger Matrix is properly configured and accessible, avoiding the bus fault issue when the debugger is disconnected. This approach leverages the debugger’s initialization capabilities to address the underlying SoC integration constraints, providing a robust solution for configuring the Cross Trigger Matrix in ARM Cortex-M4-based systems.

Conclusion

The bus fault encountered when configuring the Cross Trigger Matrix on the ARM Cortex-M4 core in the Cypress TII MCU highlights the importance of understanding the interaction between the processor core, the debug subsystem, and the SoC implementation. By recognizing the debugger-dependent behavior and the need for proper initialization, developers can implement a solution that ensures reliable access to the CTI and CTM registers. This approach not only resolves the immediate issue but also provides a framework for addressing similar challenges in other ARM-based systems.