Initial STM32H5 ICACHE Commit

[kywwilson11]

Summary

Add support for the STM32H5 ICACHE peripheral. The CortexM33 does not have typical embedded icache and dcache. Instead STM32H5 provides the ICACHE as a separate peripheral that needs to be configured. This commit adds the stm32h5 specific icache driver.

The driver named functions like those in <nuttx/cache.h>. However since the CortexM33 does not have cache itself, ARCH_ICACHE is not enabled. Therefore these stm32h5 specific functions were developed.

Impact

Impacts the STM32H5 Architecture. Changes made were:

1. Kconfig - Added options for enabling the ICACHE as well as ICACHE configuration options. Configuration included enabling interrupts, setting regions, and enabling the hit/miss counters.
2. Make.defs - Build stm32_icache.c if ICACHE is configured.
3. stm32.h - Add stm32_icache.h. Reorder based on alphabet.
4. stm32_icache.h - Function declarations.
5. hardware/stm32_icache.h - Hardware register defines for ICACHE.
6. stm32_icache.c - Driver for ICACHE. Public function names emulate those in <nuttx/cache.h>.
7. stm32_start.c - Run stm32_icache_enable if ICACHE is configured.

Testing

1. Build tests - Testing builds without warning (from cache files).
2. Cache Enabling - Testing included enabling the cache and watching hit/miss monitors.
3. Region x setup - Enabled regions in make menuconfig and confirmed registers were written properly.
4. Interrupt testing - Enabled full invalidate interrupt, made sure isr was accessed and invalidate procedure proceeded as expected.

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although the testing section could be improved.

Here's a breakdown:

Strengths:

• Clear Summary: The summary clearly explains the why, what, and how of the change. It mentions the specific hardware (STM32H5) and the lack of standard Cortex-M33 cache, justifying the need for a dedicated driver. It also describes the driver's function and how it relates to existing cache functions.
• Detailed Impact: The impact section covers all the relevant areas (Kconfig, Make.defs, header files, driver implementation, startup code). This level of detail is helpful for reviewers.
• Testing Description: The testing section outlines the test cases performed.

Weaknesses:

• Missing Issue References: While not strictly mandatory, referencing a related NuttX issue would be beneficial for tracking and context. If there isn't one, consider creating one before submitting the PR.
• Vague Testing Logs: The "Testing logs" sections are empty. Instead of simply stating what you tested, provide actual output logs (or excerpts) demonstrating the before-and-after behavior. Include specific commands used and the observed results. The screenshot is a good start, but insufficient. Quantify the hit/miss improvements. Show register values before and after configuration. Demonstrate interrupt triggering and handling.
• Missing Build Host/Target Details: The "Testing" section lacks specifics about the build host and target environments. Provide details as requested (OS, CPU, compiler, architecture, board, configuration).

Recommendations for Improvement:

1. Add Issue Reference: Link to a related NuttX issue if one exists.
2. Provide Concrete Testing Logs: Replace the placeholder comments with actual log output. Demonstrate the driver's functionality with clear before-and-after comparisons. Include commands used and expected vs. actual outputs.
3. Specify Build and Target Environments: Detail the build host (OS, CPU, compiler) and target (architecture, board, configuration) used for testing.
4. Quantify Testing Results: Instead of saying "hit/miss monitors," provide actual numbers or percentages demonstrating the impact of enabling the ICACHE.

By addressing these points, the PR will be even stronger and easier for reviewers to assess.