I've relocated the .text section of a test project to SRAM1 through the C-bus address (starting at 0x0A00 0000). I have relocated the main function into SRAM1.
The code runs fine, and if I suspend the chip and navigate to the 0x0A00 0000 address space on the disassembly view the code and debug information (function names, source code references, etc.) is present and visible.
Navigating to 0x2000 0000 on the disassembly view also displays the same assembly instructions but without any debug information
With main located in SRAM1, the debugger fails to stop on entry into main, despite the debug configuration setting.
If I set a breakpoint on any code that is located in SRAM1, the debugger does not suspend on those breakpoints, UNLESS I set a breakpoint in the reset handler (which is in FLASH), hit the breakpoint after a reset, and step into main from the reset handler, then it stops on breakpoints normally. This behavior occurs regardless of whether code is accessed via C-bus or S-bus.
If I relocate only some code into SRAM1 accessed via C-bus, with main in FLASH, then the debugger does stop on entry into main as normal, and code does stop on breakpoints set on code located in SRAM1, but then the code fails to resume execution and continues to suspend on the same location indefinitely. This behavior does not happen if the code in SRAM1 is accessed via S-bus (address 0x2000 0000) instead of the C-bus. The breakpoints behave normally if main is in FLASH and any code in SRAM1 is accessed via S-bus.
I've attached the test project's linker script below. I am also relocating a number of sections into SRAM2; that also works fine and is not an issue. The above behaviors persist with normal placement of the IVT and read-only data.
ICACHE 2-ways is enabled. FLASH Prefetch is enabled. Disabling either does not appear to affect the behavior.
Not sure if related, but relocating all of the .text section into SRAM1 causes the alignment of the reset handler to change from 4 bytes to 8 bytes.
Side note, the linker will load the.bss section into flash with a corresponding LMA unless the workarounds mentioned in the linker script are used.
I understand from AN5872 that the performance of the ICACHE is comparable with execution from SRAM1; however, the project I am working on depends on worst-case execution time, and execution from SRAM1 is deterministic. I will eventually profile the code; perhaps executing from SRAM1 may not be necessary.
