Just wanted to put this here in case anyone else runs into it.
The STM32L43xxx/44xxx/45xxx/46xxx microcontroller family has SRAM1 and SRAM2. Difference is SRAM2 has extra features like optional parity check. For this problem, I do not have parity check enabled.
When SEGGER_RTT_SECTION is not set, the linker may place _SEGGER_RTT and other RTT stuff in SRAM2 since RAM space (.data + .bss) is contiguous starting at 0x2000 0000 and there is no distinction from the linker's perspective.
When the RTT Control Block _SEGGER_RTT is put into SRAM2 part of RAM space (for example, above 0x2002 0000), SystemView cannot see it at all, whether by using Automatic Detection or even manually put in the address of _SEGGER_RTT found from .map file!
Note that _UpBuffer can still be in SRAM2 and it would still function. (i.e. SEGGER_SYSVIEW_SECTION does not need to be explicitly set to SRAM1)
The STM32L43xxx/44xxx/45xxx/46xxx microcontroller family has SRAM1 and SRAM2. Difference is SRAM2 has extra features like optional parity check. For this problem, I do not have parity check enabled.
When SEGGER_RTT_SECTION is not set, the linker may place _SEGGER_RTT and other RTT stuff in SRAM2 since RAM space (.data + .bss) is contiguous starting at 0x2000 0000 and there is no distinction from the linker's perspective.
When the RTT Control Block _SEGGER_RTT is put into SRAM2 part of RAM space (for example, above 0x2002 0000), SystemView cannot see it at all, whether by using Automatic Detection or even manually put in the address of _SEGGER_RTT found from .map file!
Note that _UpBuffer can still be in SRAM2 and it would still function. (i.e. SEGGER_SYSVIEW_SECTION does not need to be explicitly set to SRAM1)