January 22, 2021 at 08:26 #29816
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:C++1HAL_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.January 22, 2021 at 08:28 #29818
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++12345678910111213141516171819202122232425262728C:\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 v2libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3For bug reports, readhttp://openocd.org/doc/doxygen/bugs.htmlInfo : 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/SWDInfo : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWDInfo : clock speed 4000 kHzInfo : STLINK v3 JTAG v7 API v3 M2 VID 0x0483 PID 0x374EInfo : using stlink api v3Info : Target voltage: 3.226824Info : Unable to match requested speed 4000 kHz, using 3300 kHzInfo : Stlink adapter speed set to 3300 kHzInfo : STM32H747XIXx.cpu0: hardware has 8 breakpoints, 4 watchpointsError: Target not examined yetError executing event examine-end on target STM32H747XIXx.cpu0:Info : STM32H747XIXx.cpu1: hardware has 6 breakpoints, 4 watchpointsInfo : starting gdb server for STM32H747XIXx.cpu0 on 4146Info : Listening on port 4146 for gdb connectionsInfo : starting gdb server for STM32H747XIXx.cpu1 on 4147Info : Listening on port 4147 for gdb connectionstarget halted due to debug-request, current mode: ThreadxPSR: 0x01000000 pc: 0x080057f0 msp: 0x20020000Error: timed out while waiting for target haltedTARGET: STM32H747XIXx.cpu1 - Not halted
January 25, 2021 at 09:04 #29822
- This reply was modified 1 month, 1 week ago by Undici77.
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.January 26, 2021 at 10:00 #29830
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?
January 26, 2021 at 10:07 #29832
- This reply was modified 1 month ago by Undici77.
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.