STM32CubeIDE debugging issues of code placed in SRAM (STM32H7 MCU).

[kgardas]

Hello,

I'm using latest STM32CubeIDE (1.12.0) on Linux Ubuntu 20.04 and on Apple Ventura macOS on M1 mini. I'm using also stm32h757i-eval board for this testing. I'm using RTOS (RTEMS) code for testing, but IMHO it's not a problem of RTOS/RTEMS here.

What I see is:

• code linked to FLASH: I'm able to step as I'd like to and I'm able to resume execution as I like to. For test I'm using 3 breakpoints
• code linked into SRAM (AXI SRAM): I'm not able to step as I'd like to. Some functions blocks debugging forever. Debugger shows it's running a Step, but nothing happen after that. Also when testing my 3 breakpoints setup, I'm able to resume only exactly once. On second resume the code stop always on the second breakpoint in the row and can't move forward from execution point of view. When I switch to instruction stepping and follows PC reg, on step it does not move forward.

Remark: I'm testing here the *same* code with the same breakpoints set into it. The only difference is linkage either into flash (working as expected) or to axi sram (buggy).

Let me ask, has anybody reported this behavior already? Is there anything I shall do to fix that on my side? Am I doing any mistake which prevents IDE/debugger to work as expected?

Thanks!

Karel

[kgardas]

More investigation. On Linux solely I've also tried older version of STM32CubeIDE. Versions:

• 1.10.1
• 1.10.0
• 1.9.0
• 1.8.0

except 1.8.0 which breaks even on starting debugger, all of them exhibit the same behavior like 1.12.0.

[kgardas]

Since the issue seems to be with putting breakpoints in RAM and breakpoints in FLASH seems to behave correctly, I've got an idea to test to use hardware breakpoints in RAM too. For this test I'm starting ST-LINK gdb server from IDE distribution (1.12.0) on command-line and use also command-line version of gdb. I'm using 'hbreak' command in gdb to set hardware breakpoints on all 3 places form the test above and then hitting 'c' (for continue) to see how resume works.

Conclusion: command-line tools behave exactly like IDE itself. First resume works and on second I'm in loop and can't proceed. So basically IDE shows just an issue with underlying ST-LINK server.

[kgardas]

Since ST-Link GDB server seems to be the culprit here, I've attempted to test STMicro fork of openocd to see if this behaves in a same way or better/worse. I'm using this:

Open On-Chip Debugger 0.12.0-rc1+dev-00974-ga79285f2f (2023-03-14-14:42) [https://github.com/STMicroelectronics/OpenOCD]

And for my STM32H757i-eval board I'm starting with configuration for h747i-disco which should be most close probably:

$ ./bin/openocd -f share/openocd/scripts/board/stm32h747i-disco.cfg

Using command-line gdb with 'hbreak' command like from ST-Link GDB server test above. When placing all 3 hbreaks on the 3 tested places and hitting 'c' command to continue, I'm happy to report that this thing behaves correctly and does not cycle on 2nd breakpoint.

OpenOCD is not panacea as it has its own set of issues, but at least this test shows that hardware is capable of placing hardware break into SRAM and GDB is able to behave accordingly.

[Pavel A.]

Whatever it's worth - this issue should be specific to multicore STM32H7​ or Linux/Unix ST-LINK s/w versions.

I often use RAM based programs with single core STM32H743/753 (and STM32F7) - never seen any such issues with step and breakpoints. (on Windows, though. Macs are prettier, but Windows just works better).

[kgardas]

Hello Pavel,

thanks a lot for your report. It gets me thinking more and evaluating more. Let me throw some results of investigation here:

• all the time my stm32h757i-eval board was running single-core only. Only CM7 was enabled and CM4 was disabled.
• I've installed STM32CubeIDE also on my Windows 10 and repeated the test there and with the same result
• I've also picked up Nucleo h743zi from my drawer and test it on Linux (this is more easier for me than on Windows or macOS) and this shows exactly the same issue like my eval board. So what is working for you, is not working for me.

Hence my hypothesis is that I need to investigate code directly. The code looks:

 55 void bsp_start_hook_0(void)
 56 {
 57 if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
 58 /*
 59 * Only perform the low-level initialization if necessary. An initialized
 60 * FMC indicates that a boot loader already performed the low-level
 61 * initialization.
 62 */
 63 SystemInit();
 64 stm32h7_init_power();
 65 stm32h7_init_oscillator();
 66 stm32h7_init_clocks();
 67 stm32h7_init_peripheral_clocks();
 68 HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI, RCC_MCODIV_1);
 69 HAL_Init();
 70 SystemInit_ExtMemCtl();
 71 }
 72 
 73 #if __CORTEX_M == 0x07U
 74 if ((SCB->CCR & SCB_CCR_IC_Msk) == 0) {
 75 SCB_EnableICache();
 76 }
 77 
 78 if ((SCB->CCR & SCB_CCR_DC_Msk) == 0) {
 79 SCB_EnableDCache();
 80 }
 81 
 82 _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, stm32h7_config_mpu_region_count);
 83 #endif
 84 }
 85 
 86 void bsp_start_hook_1(void)
 87 {
 88 bsp_start_copy_sections_compact();
 89 #if __CORTEX_M == 0x07U
 90 SCB_CleanDCache();
 91 SCB_InvalidateICache();
 92 #endif
 93 bsp_start_clear_bss();
 94 stm32h7_init_qspi();
 95 }

the code is available here: https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c -- the same code for nucleo h743zi is here too:

https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c

Now, when you know code let me add that

• first breakpoint is right on bsp_start_hook_0
• second breakpint is right on bsp_start_hook_1
• third is in user (hello world app) Init function here: https://git.rtems.org/rtems/tree/testsuites/samples/hello/init.c -- but this is not important

As you can see between 1st (working continue) and 2nd (not working continue) breakpoint is the code which enables I cache, e.g. SCB_EnableICache(). The idea is that it may breaks breakpoint here and indeed, I've been able to verify that if I disable:

• SCB_EnableICache();
• SCB_InvalidateICache();

lines, my test is working correctly. E.g. I can continue from all three breakpoints correctly. No infinite loop on second breakpoint.

So it is interesting that enabled I cache behaves differently when serving code from flash or from axi sram, but it looks like this is the case. H7 memory map claims cache is set differently for those so perhaps this is the reason?

Anyway, thanks for your feedback! It pushed me forward a lot!

Karel

[Piranha]

SCB_CleanDCache();

Are you sure this doesn't cause some collateral damage at that point? No DMAs transferring something to the memory?

Not directly related, but just for the ideas:

https://github.com/ARM-software/CMSIS_5/commit/36bd54f7963825954b3dd37c036dbbcd1494988f

https://community.st.com/s/question/0D53W00001Z9K9TSAV/maintaining-cpu-data-cache-coherence-for-dma-buffers

[kgardas]

I'm pretty sure as this is BSP initialization or in fact very early initialization. There are no drivers enabled yet who would do any form of DMA at that time. But thanks a lot for the pointer as I'm pretty sure I'll be able to hit that in the future anyway. :)

[Pavel A.]

So, are you using now OpenOCD or ST GDB server?

Note that breakpoint at SCB_****Cache and stepping thru these does not work for me. The symptom is same: looping forever, not making progress.

Don't know why, just learned to always run thru these macros at full speed.

[kgardas]

I'm still using ST GDB server as RTEMS testing infrastructure is not prepared for OpenOCD yet. Besides this ST GDB server issue with breakpoints after instruction cache is enabled, it also does have some other quirks which I'd like to test on and compare with OpenOCD if they are present or not. So yes, I'll need to become more familiar with OpenOCD indeed.

BTW: based on other user advice I've reported the issue to ST and some engineer is assigned to it, so we will see what he/she thinks about it too.