2023-03-14 04:05 AM
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:
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
2023-03-15 03:05 AM
More investigation. On Linux solely I've also tried older version of STM32CubeIDE. Versions:
except 1.8.0 which breaks even on starting debugger, all of them exhibit the same behavior like 1.12.0.
2023-03-15 03:25 AM
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.
2023-03-15 03:30 AM
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.
2023-03-19 04:58 PM
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).
2023-03-20 03:59 AM
Hello Pavel,
thanks a lot for your report. It gets me thinking more and evaluating more. Let me throw some results of investigation here:
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
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:
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
2023-03-22 12:16 PM
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
2023-03-22 12:20 PM
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. :)
2023-03-22 07:30 PM
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.
2023-03-23 01:36 AM
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.