If octospi is enabled system memory is mapped at 0x00 after reset even thought flash should be mapped.

[Seegras]

Dear all,

I am using a NUCLEO-L4R5ZI board and am trying to get the octospi interface running in quad mode.

After generating the code I tried to run the generated code in the STM32CubeIDE but failed to debug it. Since it seems that the system memory gets mapped at address 0x0.

This is visible if the memory regions 0x0, 0x80000000 and 0x1FF0000 are compared in the memory browser while breaking at the reset vector.

The issue gets more transparent during the call to __HAL_RCC_SYSCFG_CLK_ENABLE(); in the file stm32l4xx_hal_msp.c since then the MEM_MODE is changed to 0x01 in the SYSCFG-MEMRMP register.

After a while (IRQ?), the code execution in the debugger jumps to the address range above 0x1FF00000 and I have to restart the debugger to come to the reset vector of my code. (Makes sense since the VTOR base address is not 0x0 anymore.

If I remove the call to  MX_OCTOSPI1_Init(); in the main function everything works as expected.

During some experiments I realized that if I remove the call to  MX_OCTOSPI1_Init(); and remove the -Wl, --gc-sections option to keep unused sections the issue persists.

This gives me the impressions that the added code by the OCTOSPI peripheral introduces some issues.

Does any one know, if enabling the octospi interface in STM32CubeMX might change something in the binary which affects the used memory mapping mode even before the reset vector? Since the boot0 pin is kept low and the FLASH_OPTR register is still at default value I am not sure what could affect the SYSCFG-MEMRMP register.

Thank you very much for any hint or help which might point me into the right direction.

If needed I attached the zipped project folder as a reference.

With best regards,

Flavio

[Seegras]

This looks like a related question to me: https://community.st.com/s/question/0D53W00000wU7iPSAS/inconsistent-vector-table-on-nucleo-with-stm32l4r5

[Seegras]

I modified now the file startup_stm32l4r5zitx.s to reset SYSCFG_MEMRMP to 0 and SCB->VTOR to 0 as recommended in the post above.

As described there it brings me a small step forward. But as soon as I am resetting the target from the STM32CubeIDE the MEM_MODE is changed again.

Could it be that STLink is modifying some things unintentionally?

[Seegras · Accepted solution]

Ok, it seems that it was an issue with stlink.

After updating the on-board debugger to SEGGEr J-Link as instructed here: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

With the SEGGER debug connection the issue seems gone. But we will see if this persists.