How to Debug STM32N645 above 0x34200000

[mraehle]

Hi 
I have setup a small project in CubeMX v6.17.0 with FSBL and an application (secure domain only). As long as I use the default Flash and RAM region, debugging works fine. 

  ROM    (xrw)    : ORIGIN = 0x34000400,   LENGTH = 511K
  RAM    (xrw)    : ORIGIN = 0x34080000,   LENGTH = 1536K

In the future the application will be way bigger (using TouchGFX), therfore I increased the Flash Region to 1.5 MB and the RAM Region will start at 0x34200000 with a length of 1.5 MB as well. 

  ROM    (xrw)    : ORIGIN = 0x34000400,   LENGTH = 1536K
  RAM    (xrw)    : ORIGIN = 0x34200000,   LENGTH = 1536K

Since I made this change it is not possible to step into the application. FSBL works well and is loading the App data from external Flash into SRAM (0x34000000) as requested. After jumping into the app connection to target is lost as soon as SystemInit funciton is called. Debugger can't write any more: 

Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
0x3400095a in SystemInit () at ../Core/Src/system_stm32n6xx_s.c:177

Has someone an idea what the problem could be.

thanks a lot
Markus

[mraehle · Accepted solution]

Finally I found the reason why it was not possible to run code RAM 0x3420'0000 and above. 
CubeMX didn't power on the SRAM3, 4, 5 and 6, even though they were activated in CubeMX. This might be a bug in CubeMX. @stm Please fix that. I used STM32CubeMX v6.17.0

I had to add the following code into main.c of FSBL

  /* USER CODE BEGIN SysInit */

  /* Power up AXI SRAM3-6 and enable their memory clocks.
   * SRAMSD bit must be cleared BEFORE enabling the clock.
   * Without this, SRAM3-6 are physically shut down even after RAMCFG_Init. */
  __HAL_RCC_RAMCFG_CLK_ENABLE();

  /* SRAM3 */
  RAMCFG_SRAM3_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
  HAL_Delay(1);
  __HAL_RCC_AXISRAM3_MEM_CLK_ENABLE();

  /* SRAM4 */
  RAMCFG_SRAM4_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
  HAL_Delay(1);
  __HAL_RCC_AXISRAM4_MEM_CLK_ENABLE();

  /* SRAM5 */
  RAMCFG_SRAM5_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
  HAL_Delay(1);
  __HAL_RCC_AXISRAM5_MEM_CLK_ENABLE();

  /* SRAM6 */
  RAMCFG_SRAM6_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
  HAL_Delay(1);
  __HAL_RCC_AXISRAM6_MEM_CLK_ENABLE();

  /* USER CODE END SysInit */

[Mikk Leini]

I reported the same problem:

https://community.st.com/t5/stm32cubemx-mcus/cubemx-fails-to-load-ioc-file-after-enabling-ramcfg/m-p/882479/highlight/true#M35257

But it appears ST is not responding if forum topic has already some answer.

[Amel NASRI]

Hi @Mikk Leini ,

Sorry to hear that, and thank you for raising it. This is not a general rule, although it can sometimes happen. To help us keep track and follow up properly, we recommend one topic per thread, so I’ll move the new reply from the other thread into a separate discussion (see https://community.st.com/t5/stm32cubemx-mcus/sram3-4-5-and-6-clock-enable-missing-in-stm32cubemx-generated/td-p/882479).

@mraehle, glad to know that you find a solution. I'll push for a fix in STM32CubeMX.

-Amel