- This topic has 4 replies, 2 voices, and was last updated 3 years, 10 months ago by
.
-
Posts
-
Hello,
I’m working on STM32H747I-Disco and following this guide https://visualgdb.com/tutorials/arm/stm32/multicore/startup/ I can debug my 2 projects on M7 and M4.
In order to create a custom Bootloader con M7, I tried to change the Option Bit inside BCM4 so, after reset M7 boot and M4 has clock gated. This is a common practice in order to boot M7, perform flash update of M4 and start M4 with API:
HAL_RCCEx_EnableBootCore(RCC_BOOT_C2);
This solution is working and debugger work with STM Environment, but I can’t find a way to use VisualGDB to upload firmware inside M7, wait the boot of M7, and when M4 is started, unload firmware in M4 and start debug.
Watching GDB Log, it looks like I can’t start to upload firmware on M7 core if M4 core is gated.
This is log error extracted from GDB:
C:\Users\undici77\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd_hla_multicore.exe -c "gdb_port 4146" -c "telnet_port 4145" -f interface/stlink.cfg -f C:/Users/undici77/AppData/Local/Temp/tmp53C5.tmp -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.10.0 (2020-05-30) [https://github.com/sysprogs/openocd] Licensed under GNU GPL v2 libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 4000 kHz Info : STLINK v3 JTAG v7 API v3 M2 VID 0x0483 PID 0x374E Info : using stlink api v3 Info : Target voltage: 3.226824 Info : Unable to match requested speed 4000 kHz, using 3300 kHz Info : Stlink adapter speed set to 3300 kHz Info : STM32H747XIXx.cpu0: hardware has 8 breakpoints, 4 watchpoints Error: Target not examined yet Error executing event examine-end on target STM32H747XIXx.cpu0: Info : STM32H747XIXx.cpu1: hardware has 6 breakpoints, 4 watchpoints Info : starting gdb server for STM32H747XIXx.cpu0 on 4146 Info : Listening on port 4146 for gdb connections Info : starting gdb server for STM32H747XIXx.cpu1 on 4147 Info : Listening on port 4147 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080057f0 msp: 0x20020000 Error: timed out while waiting for target halted TARGET: STM32H747XIXx.cpu1 - Not halted
Hi,
Both VisualGDB and STM32CubeIDE perform debugging using the open-source OpenOCD tool. OpenOCD is normally started by passing it a few initialization scripts that configure it. Once it is initialized, it begins listening for incoming connections from GDB.
If you encounter different behavior with VisualGDB vs. STM32CubeIDE, most likely, OpenOCD is launched with different parameters/scripts. If this is the case, please try extracting the OpenOCD command lines from both VisualGDB and STM32CubeMX and try running them manually. If OpenOCD behaves differently, please compare the 2 command lines and try experimenting with them to see what difference is affecting the issue.
If the OpenOCD script used by STM32CubeIDE is different from VisualGDB’s one, we would advise simply copying it to the project directory and manually overriding the OpenOCD command line in VisualGDB Project Properties -> Debug Settings to run it. If the command lines appear identical, please try checking if using the OpenOCD executable from the STM32CubeIDE instead of the VisualGDB-supplied executable changes anything.
Thanks for answer!
I found something interesting:
- CubeIde use generic script stm32h7x.cfg and download both .elf at the same time, as explained in AN8256 STM32H7x5/x7 dual-core microcontroller debugging
- Visual GDB use stm32h7x_dual_core.cfg
Can you provide a solution, in order to debug a firmware with CM4 gated on reset?
Hi,
The scripts used by VisualGDB are taken from the original OpenOCD repository (see our fork on github) where they are contributed by ST.
As the scenario you described is relatively rare, the regular OpenOCD scripts (used by VisualGDB) likely do not support it. Once ST contributes updated scripts supporting this properly, our OpenOCD package will include them as well, and VisualGDB will support it out-of-the-box.
Until then, our best advice would be to simply copy the STM32CubeIDE script to your project directory and configure VisualGDB to use it instead of the regular script. You can tweak the OpenOCD command line used by VisualGDB via VisualGDB Project Properties -> Debug Settings -> Advanced. Use can use the $(ProjectDir.forwardslashes) variable to avoid hardcoding the absolute path to the project directory.
- You must be logged in to reply to this topic.