ARM PL310 L2 Cache Controller SLVERR Interrupt Not Raised in ISR
The ARM PL310 Level 2 Cache Controller (L2C) is a critical component in many ARM-based systems, providing high-performance caching mechanisms to optimize memory access. However, a specific issue arises when attempting to handle AXI slave errors (SLVERR) within the PL310 L2C, particularly when these errors are expected to trigger interrupts in the Interrupt Status Register (ISR) or Interrupt Pending Register (IPR). In this scenario, the SLVERR interrupt is not being raised in the ISR of the PL310 L2C, despite the AXI slave error being correctly propagated through the system and causing a data abort exception at the CPU level. This issue is particularly relevant in systems where fine-grained exception handling is required, such as in the Xilinx Zynq SoC with the ARM PL310 revision r3p2.
The core of the problem lies in the interaction between the AXI bus protocol, the PL310 L2C, and the CPU’s exception handling mechanism. When an AXI slave error occurs on a non-DDRC peripheral connected to the L2C, the error is expected to be captured by the PL310 L2C and reflected in its interrupt registers. However, in this case, the error is correctly propagated back to the CPU, causing a data abort exception, but the corresponding SLVERR interrupt is not set in the PL310 L2C’s ISR or IPR. This discrepancy suggests a potential misconfiguration or misunderstanding of the PL310 L2C’s error handling mechanisms, particularly with respect to non-cacheable and strongly ordered memory accesses.
Non-Cacheable Strongly Ordered Accesses and PL310 L2C Error Reporting
The ARM PL310 L2C is designed to handle various types of memory transactions, including cacheable, non-cacheable, and strongly ordered accesses. According to the PL310 Technical Reference Manual (TRM), the L2C is expected to raise SLVERR or DECERR interrupts when an AXI slave error occurs during specific types of transactions. However, the TRM also indicates that non-cacheable strongly ordered accesses to slave peripherals by the L2C do not raise an exception in the L2C itself. This behavior is consistent with the observed issue, where the AXI slave error is propagated to the CPU but not reflected in the PL310 L2C’s interrupt registers.
The PL310 L2C’s error reporting mechanism is closely tied to the type of memory access being performed. For cacheable read transactions, the L2C will attempt to allocate a cache line and load the data into the data RAM. If an error occurs during this process, the L2C will not update the tag RAM and will raise the corresponding SLVERR or DECERR interrupt. However, for non-cacheable strongly ordered accesses, the L2C does not perform these actions, and as a result, the error is not captured by the L2C’s interrupt mechanism. Instead, the error is passed directly back to the CPU, which then raises a data abort exception.
This behavior is further clarified in the PL310 TRM, which states that the error response for non-cacheable read transactions and non-bufferable write transactions is precise and is passed back to the processor using a read response on the slave port read channel or the write response channel. This means that the L2C does not generate an interrupt for these types of transactions, as the error is handled directly by the CPU. This understanding aligns with the observed behavior in the Xilinx Zynq SoC, where the AXI slave error is correctly propagated to the CPU but not reflected in the PL310 L2C’s interrupt registers.
Configuring PL310 L2C for SLVERR Interrupt Handling and Debugging Steps
To address the issue of SLVERR interrupts not being raised in the PL310 L2C’s ISR, it is essential to understand the configuration and behavior of the L2C in relation to different types of memory accesses. The following steps outline the necessary actions to diagnose and potentially resolve the issue:
1. Verify PL310 L2C Configuration:
The first step is to ensure that the PL310 L2C is correctly configured to handle AXI slave errors. This includes checking the L2C’s control registers to confirm that the appropriate interrupt enable bits are set. Specifically, the SLVERR and DECERR interrupt enable bits in the PL310 L2C’s Interrupt Mask Register (IMR) should be enabled to allow the L2C to generate interrupts for these types of errors. Additionally, the L2C’s Auxiliary Control Register (ACR) should be reviewed to ensure that the appropriate cache policies are in place for the memory regions being accessed.
2. Analyze Memory Access Patterns:
The next step is to analyze the memory access patterns that are causing the AXI slave errors. This involves reviewing the software code and hardware design to identify the specific memory transactions that are generating the errors. Particular attention should be paid to non-cacheable strongly ordered accesses, as these are the types of transactions that are not expected to raise interrupts in the PL310 L2C. If the errors are occurring during these types of accesses, it may be necessary to modify the software or hardware design to use cacheable accesses instead.
3. Implement Data Synchronization Barriers:
In some cases, the issue may be related to the timing of cache operations and memory accesses. To ensure that the PL310 L2C’s cache is properly synchronized with the rest of the system, data synchronization barriers (DSBs) and data memory barriers (DMBs) should be implemented in the software code. These barriers ensure that all pending memory operations are completed before proceeding to the next instruction, which can help to prevent timing-related issues that may be causing the AXI slave errors.
4. Debugging with Hardware Trace and Logging:
To further diagnose the issue, hardware trace and logging tools can be used to capture detailed information about the memory transactions and error responses. This includes using the ARM CoreSight™ Embedded Trace Macrocell (ETM) to trace the execution of the software code and the AXI bus transactions. Additionally, the PL310 L2C’s debug registers can be used to log the occurrence of AXI slave errors and the corresponding interrupt status. This information can be invaluable in identifying the root cause of the issue and determining the appropriate corrective actions.
5. Review and Update Firmware:
Finally, it may be necessary to review and update the firmware to ensure that it is correctly handling the AXI slave errors and the corresponding data abort exceptions. This includes implementing appropriate exception handlers to manage the errors and ensure that the system can recover gracefully. Additionally, the firmware should be reviewed to ensure that it is correctly configuring the PL310 L2C and the memory access patterns to avoid generating AXI slave errors in the first place.
In conclusion, the issue of SLVERR interrupts not being raised in the PL310 L2C’s ISR is a complex problem that requires a thorough understanding of the PL310 L2C’s error handling mechanisms and the memory access patterns in the system. By following the steps outlined above, it is possible to diagnose and resolve the issue, ensuring that the PL310 L2C is correctly configured to handle AXI slave errors and that the system can recover gracefully from these errors.
