Debug STM32H747XI dual core when CM4 is gated

Sysprogs forums Forums VisualGDB Debug STM32H747XI dual core when CM4 is gated

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #29816
    Undici77
    Participant

    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.

    #29818
    Undici77
    Participant

    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
    
    
    
    • This reply was modified 3 years, 10 months ago by Undici77.
    #29822
    support
    Keymaster

    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.

    #29830
    Undici77
    Participant

    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?

    • This reply was modified 3 years, 10 months ago by Undici77.
    #29832
    support
    Keymaster

    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.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.