ARM Cortex-M7 DWT Counter Overflow and Instruction Counting Inaccuracy
The ARM Cortex-M7 processor provides a set of Debug Watchpoint and Trace (DWT) counters that are commonly used for profiling and performance analysis. These counters include DWT_CYCCNT (cycle count), DWT_CPICNT (CPI count), DWT_EXCCNT (exception overhead count), DWT_SLEEPCNT (sleep count), DWT_LSUCNT (load/store unit count), and DWT_FOLDCNT (folded instruction count). The formula to calculate the number of instructions executed is:
[ \text{instructions executed} = \text{DWT_CYCCNT} – \text{DWT_CPICNT} – \text{DWT_EXCCNT} – \text{DWT_SLEEPCNT} – \text{DWT_LSUCNT} + \text{DWT_FOLDCNT} ]
However, a significant limitation arises due to the fact that DWT_CPICNT, DWT_EXCCNT, DWT_SLEEPCNT, DWT_LSUCNT, and DWT_FOLDCNT are only 8-bit registers. This means they can only count up to 255 before overflowing. When these counters overflow, the instruction count becomes inaccurate, as the overflow events are not accounted for in the calculation. This limitation makes it challenging to accurately profile long-running tasks or large code segments where the number of instructions exceeds the 8-bit counter capacity.
The Cortex-M7’s DWT counters are designed to provide fine-grained profiling data, but the 8-bit limitation of some counters introduces a trade-off between precision and the duration of the profiling session. For short bursts of code execution, the counters work well, but for longer durations, the overflow issue becomes a critical bottleneck. This is particularly problematic in real-time systems or performance-critical applications where accurate instruction counting is essential for optimizing code and meeting timing constraints.
8-Bit Counter Overflow and Lack of Overflow Handling Mechanism
The root cause of the instruction counting inaccuracy lies in the 8-bit width of the DWT_CPICNT, DWT_EXCCNT, DWT_SLEEPCNT, DWT_LSUCNT, and DWT_FOLDCNT registers. These counters are designed to track specific events during program execution, such as cycles per instruction (CPI), exception overhead, sleep cycles, load/store operations, and folded instructions. However, their 8-bit width limits their range to 0-255, after which they overflow and reset to zero.
When an overflow occurs, the counter loses track of the number of events that have been counted, leading to an undercount in the total instruction count. For example, if DWT_CPICNT overflows multiple times during a profiling session, the total CPI count will be significantly lower than the actual number of CPI events. This undercount propagates through the instruction count formula, resulting in an inaccurate total instruction count.
Another contributing factor is the lack of an overflow handling mechanism in the DWT counters. Unlike DWT_CYCCNT, which is a 32-bit counter and can be manually cleared or extended using software, the 8-bit counters do not provide a straightforward way to detect or handle overflows. This makes it difficult to maintain accurate instruction counts over extended periods or for large code segments.
The Cortex-M7’s architecture does not include hardware support for automatically extending the 8-bit counters or capturing overflow events. This places the burden on the software developer to implement workarounds, such as periodic sampling or manual overflow tracking, which can introduce additional complexity and overhead.
Implementing Software-Based Overflow Tracking and Extended Profiling
To address the limitations of the 8-bit DWT counters and achieve accurate instruction counting on the Cortex-M7, a software-based approach can be employed. This approach involves implementing overflow tracking and extending the effective range of the counters through periodic sampling and manual overflow handling.
Step 1: Periodic Sampling of DWT Counters
The first step is to implement a periodic sampling mechanism that reads the DWT counters at regular intervals before they overflow. By sampling the counters frequently, the software can capture their values and accumulate the counts in larger variables, effectively extending the range of the counters.
For example, a timer interrupt can be configured to trigger at a frequency that ensures the 8-bit counters are sampled before they reach their maximum value. During each interrupt, the values of DWT_CPICNT, DWT_EXCCNT, DWT_SLEEPCNT, DWT_LSUCNT, and DWT_FOLDCNT are read and added to 32-bit accumulator variables. The counters are then reset to zero to prepare for the next sampling interval.
Step 2: Manual Overflow Tracking
In addition to periodic sampling, manual overflow tracking can be implemented to detect and handle overflows that occur between sampling intervals. This involves monitoring the 8-bit counters and incrementing a separate overflow counter each time an overflow is detected.
For example, if DWT_CPICNT is read and its value is less than the previous reading, an overflow has occurred. The software can increment a 32-bit overflow counter for DWT_CPICNT and adjust the accumulated count accordingly. This ensures that the total count remains accurate even if multiple overflows occur between sampling intervals.
Step 3: Extended Profiling with Accumulated Counts
Once the periodic sampling and overflow tracking mechanisms are in place, the accumulated counts can be used to calculate the total number of instructions executed. The formula for instruction counting is modified to include the accumulated counts and overflow counters:
[ \text{instructions executed} = \text{DWT_CYCCNT} – (\text{accumulated_CPICNT} + \text{overflow_CPICNT} \times 256) – (\text{accumulated_EXCCNT} + \text{overflow_EXCCNT} \times 256) – (\text{accumulated_SLEEPCNT} + \text{overflow_SLEEPCNT} \times 256) – (\text{accumulated_LSUCNT} + \text{overflow_LSUCNT} \times 256) + (\text{accumulated_FOLDCNT} + \text{overflow_FOLDCNT} \times 256) ]
This extended formula accounts for the overflow events and provides an accurate instruction count over long profiling sessions.
Step 4: Optimizing Sampling Frequency and Overhead
The sampling frequency must be carefully chosen to balance the trade-off between accuracy and overhead. A higher sampling frequency reduces the likelihood of missed overflows but increases the interrupt handling overhead. Conversely, a lower sampling frequency reduces overhead but increases the risk of missed overflows.
To optimize the sampling frequency, the expected maximum count rate for each counter should be considered. For example, if DWT_CPICNT is expected to increment at a rate of 100 counts per millisecond, a sampling interval of 2 milliseconds would ensure that the counter is sampled before it overflows. The sampling interval can be adjusted based on the specific requirements of the application and the expected count rates.
Step 5: Validating the Extended Profiling Mechanism
After implementing the software-based overflow tracking and extended profiling mechanism, it is essential to validate its accuracy. This can be done by comparing the instruction counts obtained using the extended mechanism with known benchmarks or by profiling code segments with a predictable number of instructions.
For example, a simple loop with a fixed number of iterations can be profiled to verify that the instruction count matches the expected value. Any discrepancies should be investigated and addressed by adjusting the sampling frequency, overflow tracking logic, or accumulator variables.
Step 6: Integrating with Existing Profiling Tools
The extended profiling mechanism can be integrated with existing profiling tools and frameworks to provide a seamless experience for developers. For example, the accumulated counts and overflow counters can be exposed through a profiling API, allowing developers to access accurate instruction counts without needing to implement the overflow tracking logic themselves.
Additionally, the extended profiling mechanism can be combined with other profiling techniques, such as function-level profiling or cache performance analysis, to provide a comprehensive view of the system’s performance.
Step 7: Handling Edge Cases and Corner Conditions
Finally, it is important to consider edge cases and corner conditions that may affect the accuracy of the extended profiling mechanism. For example, if the sampling interval coincides with an overflow event, the counter may be read just before or just after the overflow, leading to an incorrect count.
To handle such cases, additional logic can be implemented to detect and correct for near-overflow conditions. For example, if a counter is read and its value is close to the maximum (e.g., 250), the software can assume that an overflow is imminent and adjust the accumulated count accordingly.
Conclusion
Accurate instruction counting on the ARM Cortex-M7 is challenging due to the 8-bit width of some DWT counters and the lack of overflow handling mechanisms. However, by implementing a software-based approach that includes periodic sampling, manual overflow tracking, and extended profiling, developers can overcome these limitations and achieve accurate instruction counts over long profiling sessions. This approach requires careful consideration of sampling frequency, overflow handling, and validation, but it provides a robust solution for performance analysis and optimization on the Cortex-M7.
