VisualGDB – STM32U5 flashing/Debugging issues

Sysprogs forums Forums VisualGDB VisualGDB – STM32U5 flashing/Debugging issues

Tagged: 

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #34000
    AndyCap
    Participant

    Hi There,

    I’m evaluating VisualGDB looks pretty good but I am having some issues with the STM32U5A9J-DK : https://www.st.com/en/evaluation-tools/stm32u5a9j-dk.html

    First using standard OpenOCD I get the following issue:
    <div>C:\Users\andre\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 59007" -c "telnet_port 59005" -f interface/stlink.cfg -f target/stm32u5x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"</div>
    <div>Open On-Chip Debugger 0.12.0 (2023-02-02) [https://github.com/sysprogs/openocd]</div>
    <div>Licensed under GNU GPL v2</div>
    <div>libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3</div>
    <div>For bug reports, read</div>
    <div>http://openocd.org/doc/doxygen/bugs.html</div>
    <div>Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.</div>
    <div>Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD</div>
    <div>Warn : The selected adapter does not support debugging this device in secure mode</div>
    <div>Info : clock speed 500 kHz</div>
    <div>Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED</div>
    <div>Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E</div>
    <div>Info : Target voltage: 1.790855</div>
    <div>Info : [stm32u5x.cpu] Cortex-M33 r0p4 processor detected</div>
    <div>Info : [stm32u5x.cpu] target has 8 breakpoints, 4 watchpoints</div>
    <div>Info : starting gdb server for stm32u5x.cpu on 59007</div>
    <div>Info : Listening on port 59007 for gdb connections</div>
    <div>Info : Unable to match requested speed 480 kHz, using 200 kHz</div>
    <div>Info : Unable to match requested speed 480 kHz, using 200 kHz</div>
    <div>CPU in Non-Secure state</div>
    <div>[stm32u5x.cpu] halted due to debug-request, current mode: Thread </div>
    <div>xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000</div>
    <div>Info : Unable to match requested speed 4000 kHz, using 3300 kHz</div>
    <div>Info : Unable to match requested speed 4000 kHz, using 3300 kHz</div>
    <div>VisualGDB_OpenOCD_Ready</div>
    <div>Info : Listening on port 6666 for tcl connections</div>
    <div>Info : Listening on port 59005 for telnet connections</div>
    <div>Info : accepting 'gdb' connection on tcp/59007</div>
    <div>Warn : Cannot identify target as an STM32G0/G4/L4/L4+/L5/U5/WB/WL family device.</div>
    <div>Error: auto_probe failed</div>
    <div>Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.</div>
    <div>Error: attempted 'gdb' connection rejected</div>
     

    Using the opened (st fork) I can successfully attach and debug but it is having issues flashing external memory:

    C:\Users\andre\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\bin\openocd.exe -c "gdb_port 58967" -c "telnet_port 58965" -f interface/stlink-dap.cfg --set "CHIPNAME STM32U5A9NJXx" -f target/stm32u5x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
    Open On-Chip Debugger 0.10.0 (2023-01-03) [https://github.com/STMicroelectronics/OpenOCD]
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    STM32U5A9NJXx
    Info : auto-selecting first available session transport "dapdirect_swd". To override use 'transport select '.
    clock_config
    Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
    Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E
    Info : Target voltage: 1.790855
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : clock speed 3300 kHz
    Info : stlink_dap_op_connect(connect)
    Info : SWD DPIDR 0x0be12477
    DEPRECATED! use 'read_memory' not 'mem2array'
    Info : [STM32U5A9NJXx.cpu] Cortex-M33 r0p4 processor detected
    Info : [STM32U5A9NJXx.cpu] target has 8 breakpoints, 4 watchpoints
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    Info : gdb port disabled
    Info : starting gdb server for STM32U5A9NJXx.cpu on 58967
    Info : Listening on port 58967 for gdb connections
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    CPU in Non-Secure state
    [STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    VisualGDB_OpenOCD_Ready
    Info : Listening on port 6666 for tcl connections
    Info : Listening on port 58965 for telnet connections
    Info : accepting 'gdb' connection on tcp/58967
    Error executing event gdb-attach on target STM32U5A9NJXx.cpu:
    target/stm32x5x_common.cfg:265: Error: invalid command name "gdb_attach_hook"
    at file "target/stm32x5x_common.cfg", line 265
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : flash size = 4096 KiB
    Info : flash mode : dual-bank
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : flash size = 4096 KiB
    Info : flash mode : dual-bank
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : OTP size is 512 bytes, base address is 0x0bfa0000
    Info : New GDB Connection: 1, Target STM32U5A9NJXx.cpu, state: halted
    Warn : Prefer GDB command "target extended-remote :58967" instead of "target remote :58967"
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    [STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : flash size = 4096 KiB
    Info : flash mode : dual-bank
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : flash size = 4096 KiB
    Info : flash mode : dual-bank
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : OTP size is 512 bytes, base address is 0x0bfa0000
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    [STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Erasing FLASH: 0x08000000-0x08032000...
    Info : Programming FLASH (2 sections, 198624 bytes)...
    Info : Programming FLASH section 1/2 (620 bytes) at 0x08000000...
    Info : Padding image section 0 at 0x0800026c with 4 bytes
    Info : Padding image section 1 at 0x080307e4 with 12 bytes (bank write end alignment)
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    DEPRECATED! use 'read_memory' not 'mem2array'
    [STM32U5A9NJXx.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000
    DEPRECATED! use 'read_memory' not 'mem2array'
    Error: Failed to read memory at 0x00000044

     

    The version of OpenOCD currently supplied with the ST32CubeIDE IDE is a more recent version and works fine in ST32CubeIDE flashing all external memories:

    Open On-Chip Debugger 0.12.0-00017-gb153daa14 (2023-02-03-14:58) [https://github.com/STMicroelectronics/OpenOCD]

    Licensed under GNU GPL v2

    For bug reports, read

    http://openocd.org/doc/doxygen/bugs.html

    clock_config

    Info : Listening on port 6666 for tcl connections

    Info : Listening on port 4444 for telnet connections

    Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E

    Info : Target voltage: 1.792445

    Info : clock speed 8000 kHz

    Info : stlink_dap_op_connect(connect)

    Info : SWD DPIDR 0x0be12477

    Info : [STM32U599NJHxQ.cpu] Cortex-M33 r0p4 processor detected

    Info : [STM32U599NJHxQ.cpu] target has 8 breakpoints, 4 watchpoints

    Info : gdb port disabled

    Info : starting gdb server for STM32U599NJHxQ.cpu on 3333

    Info : Listening on port 3333 for gdb connections

    Info : [STM32U599NJHxQ.cpu] external reset detected

    Info : accepting 'gdb' connection on tcp/3333

    CPU in Non-Secure state

    [STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread<span class="Apple-converted-space"> </span>

    xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000

    STM32U599NJHxQ.cpu TrustZone disabled

    STM32U599NJHxQ.cpu work-area address is set to 0x20000000

    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)

    Info : TZEN = 0 : TrustZone disabled by option bytes

    Info : RDP level 0 (0xAA)

    Info : flash size = 4096 KiB

    Info : flash mode : dual-bank

    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)

    Info : TZEN = 0 : TrustZone disabled by option bytes

    Info : RDP level 0 (0xAA)

    Info : flash size = 4096 KiB

    Info : flash mode : dual-bank

    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)

    Info : TZEN = 0 : TrustZone disabled by option bytes

    Info : RDP level 0 (0xAA)

    Info : OTP size is 512 bytes, base address is 0x0bfa0000

    Info : New GDB Connection: 1, Target STM32U599NJHxQ.cpu, state: halted

    Info : accepting 'gdb' connection on tcp/3333

    Info : New GDB Connection: 2, Target STM32U599NJHxQ.cpu, state: halted

    [STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread<span class="Apple-converted-space"> </span>

    xPSR: 0xf9000000 pc: 0x08018d68 msp: 0x20270000

    Info : Padding image section 0 at 0x0800026c with 4 bytes

    [STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread<span class="Apple-converted-space"> </span>

    xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000

     

    Is there a way of using this version of OpenOCD in VisualGDB?

    Many Thanks

     

    Andy

     

    • This topic was modified 1 year ago by AndyCap.
    #34002
    bflannery
    Participant

    The microcontroller and OpenOCD have no idea how to communicate with external memory by default. I am not sure what the CubeIDE is doing in the background to initialize those peripherals (maybe semihosting or an externalLoader specifically for whatever is on the development kit).

    Anyways, here is somewhere to start with VisualGDB

    https://visualgdb.com/tutorials/arm/stm32/flash/

     

     

     

    #34003
    AndyCap
    Participant

    Hi,

    Thanks very much for the reply, I was guessing the ST version of OpenOCD has this ability built in via an external loader and you needed the 0.12 version to work with this board, I will check the exact interaction tomorrow…

    Is there a way of getting VisualGDB to flash using a command line and then start OpenOCD to attach to the target?

    Cheers

    Andy

    • This reply was modified 1 year ago by AndyCap.
    • This reply was modified 1 year ago by AndyCap.
    #34006
    support
    Keymaster

    Hi All,


    @bflannery
    , thanks for your suggestion, but the tutorial you pointed out is meant for a much more complex case – trying to program external memories (e.g. SPI FLASH) that are not supported out-of-the-box. The regular on-chip FLASH memory and the memories that have drivers from ST should not need it.


    @AndyCap
    , indeed, the OpenOCD version shipped with STM32CubeIDE comes from a different repository. ST typically adds support for new devices there, and in a few months it gets ported (with some changes) to mainline OpenOCD. Either way, please try selecting OpenOCD (ST fork) instead of the regular OpenOCD in VisualGDB Project Properties -> Debug Settings. It is based on the ST fork and should work the same way as STM32CubeIDE. If it still doesn’t work, please let us know, and we will update it based on the latest release tag from ST.

    We can also help you configure programming and debugging separately if you wish, but using the ST fork of OpenOCD should be much easier.

    #34007
    AndyCap
    Participant

    @support

    Thanks for the reply.

    I have already tried the 0.10 stfork version, the log is in my first post above.

    Basically I have this:

    1. Normal OpenOCD – Doesn’t attach to the target at all : “Cannot identify target as an STM32G0/G4/L4/L4+/L5/U5/WB/WL family device”
    2. stfork OpenOCD 0.10 – Does attach, flashes the main flash ok and can debug but it is failing to flash the external flash on the board correctly.
    3. St version OpenOCD 0.12 in CubeIDE- Everything works fine.
    4. St programmer command line – Everything works fine

    The last mainline ST openocd release is 0.11, I’m not sure if that will support this board as it is pretty new.

    Any help on using a command line to flash the devices would be great.

    Also I can’t seem to find an elf file being produced only a bin, is there an option somewhere to enable writing (or not deleting) the elf?

    One more question as well, I am using TouchGFX generating a STMCubeIDE project with is then imported into VisualGDB. When I update the project via TouchGFX and restart Visual Studio it picks up the project changes and update the VS project which is really good but is there a way of doing this without restarting Visual Studio which would be perfect?

    Thanks

     

    Andy

     

     

     

    • This reply was modified 1 year ago by AndyCap.
    #34009
    AndyCap
    Participant

    I did a little test by starting up ST 0.12 OpenOCD, using the arm-none-eabi-gdb.exe from the VisualGDB folder and an elf produced by stm32CubeIDE, everything works fine (0x90000000 is the external flash).

    Is there a way in VisualGDB of telling it to use this 0.12 OpenOCD from disk?

     

    C:\Program Files (x86)\Sysprogs\VisualGDB\Keil\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
    GNU gdb (GDB) 9.2
    Copyright (C) 2020 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from STM32U5A9J-DK-FreeRTOS.elf...
    (gdb) target remote localhost:4444
    Remote debugging using localhost:4444
    Reset_Handler () at ../Application/User/Startup/startup_stm32u599njhxq.s:62
    62 ldr sp, =_estack /* set stack pointer */
    (gdb) load
    Loading section FontFlashSection, size 0x1a8 lma 0x90000000
    Loading section TextFlashSection, size 0x10 lma 0x900001a8
    Loading section ExtFlashSection, size 0xfac0 lma 0x900001b8
    Loading section .isr_vector, size 0x26c lma 0x8000000
    Loading section .text, size 0x2a0d0 lma 0x8000270
    Loading section .rodata, size 0x2f64 lma 0x802a340
    Loading section FontSearchFlashSection, size 0x18 lma 0x802d2a4
    Loading section .init_array, size 0x1c lma 0x802d2bc
    Loading section .fini_array, size 0x8 lma 0x802d2d8
    Loading section .data, size 0x130 lma 0x802d2e0
    Start address 0x08001900, load size 249988
    Transfer rate: 91 KB/sec, 10869 bytes/write.
    (gdb)

     

     

    C:\>C:\ST\STM32CubeIDE_1.12.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.2.300.202301161003\tools\bin\openocd.exe "-f" "STM32U5A9J-DK-FreeRTOS.cfg" "-s" "C:/Users/andre/source/repos/STM32/ExampleTGFX/STM32CubeIDE" "-s" "C:/ST/STM32CubeIDE_1.12.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.500.202302091318/resources/openocd/st_scripts" "-s" "C:/ST/STM32CubeIDE_1.12.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 4444" "-c" "tcl_port 7777" "-c" "telnet_port 5555"
    Open On-Chip Debugger 0.12.0-00017-gb153daa14 (2023-02-03-14:58) [https://github.com/STMicroelectronics/OpenOCD]
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    clock_config
    Info : Listening on port 7777 for tcl connections
    Info : Listening on port 5555 for telnet connections
    Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E
    Info : Target voltage: 1.793634
    Info : clock speed 8000 kHz
    Info : stlink_dap_op_connect(connect)
    Info : SWD DPIDR 0x0be12477
    Info : [STM32U599NJHxQ.cpu] Cortex-M33 r0p4 processor detected
    Info : [STM32U599NJHxQ.cpu] target has 8 breakpoints, 4 watchpoints
    Info : gdb port disabled
    Info : starting gdb server for STM32U599NJHxQ.cpu on 4444
    Info : Listening on port 4444 for gdb connections
    Info : [STM32U599NJHxQ.cpu] external reset detected
    Info : accepting 'gdb' connection on tcp/4444
    CPU in Non-Secure state
    [STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000
    STM32U599NJHxQ.cpu TrustZone disabled
    STM32U599NJHxQ.cpu work-area address is set to 0x20000000
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : flash size = 4096 KiB
    Info : flash mode : dual-bank
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : flash size = 4096 KiB
    Info : flash mode : dual-bank
    Info : device idcode = 0x30006481 (STM32U59/U5Axx - Rev 'unknown' : 0x3000)
    Info : TZEN = 0 : TrustZone disabled by option bytes
    Info : RDP level 0 (0xAA)
    Info : OTP size is 512 bytes, base address is 0x0bfa0000
    Info : New GDB Connection: 1, Target STM32U599NJHxQ.cpu, state: halted
    Warn : Prefer GDB command "target extended-remote :4444" instead of "target remote :4444"
    [STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000
    Info : Padding image section 0 at 0x0800026c with 4 bytes
    [STM32U599NJHxQ.cpu] halted due to debug-request, current mode: Thread
    xPSR: 0xf9000000 pc: 0x08001900 msp: 0x20270000

    • This reply was modified 1 year ago by AndyCap.
    #34011
    AndyCap
    Participant

    I also just tried with another board https://www.st.com/en/evaluation-tools/stm32h747i-disco.html#overview

    First issue is that the ram setup seems to be wrong for the stm32h747xi, see attached image.

    When I try to flash, I get a stack warning (I’m guessing because of the above) using:

    MEMORY
    {
    RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K /* Memory is divided. Actual start is 0x08000000 and actual length is 2048K */
    QSPI (rx) : ORIGIN = 0x90000000, LENGTH = 128000K
    DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
    RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
    RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
    ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
    }

     

    Then with both the normal and st 0.10 versions it fails to flash and even run (Failed to start GDB Session window)

     

    Here is the log from the st version:

     

    C:\Users\andre\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\bin\openocd.exe -c "gdb_port 49515" -c "telnet_port 49513" -f interface/stlink-dap.cfg --set "CHIPNAME STM32H747XIXx" -f target/stm32h7x_dual_core.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
    Open On-Chip Debugger 0.10.0 (2023-01-03) [https://github.com/STMicroelectronics/OpenOCD]
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    STM32H747XIXx
    Info : auto-selecting first available session transport "dapdirect_swd". To override use 'transport select '.
    stm32h7x_cti_prepare_restart_one
    Info : STLINK V3J11M3 (API v3) VID:PID 0483:374E
    Info : Target voltage: 3.284127
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : clock speed 3300 kHz
    Info : stlink_dap_op_connect(connect)
    Info : SWD DPIDR 0x6ba02477
    Info : [STM32H747XIXx.cm7] Cortex-M7 r1p1 processor detected
    Info : [STM32H747XIXx.cm7] target has 8 breakpoints, 4 watchpoints
    Error: [STM32H747XIXx.cm4] Cortex-M PARTNO 0x0 is unrecognized
    Warn : target STM32H747XIXx.cm4 examination failed
    Info : gdb port disabled
    Info : starting gdb server for STM32H747XIXx.cm7 on 49515
    Info : Listening on port 49515 for gdb connections
    Info : starting gdb server for STM32H747XIXx.cm4 on 49516
    Info : Listening on port 49516 for gdb connections
    Error: [STM32H747XIXx.cm4] Cortex-M PARTNO 0x0 is unrecognized
    Info : [STM32H747XIXx.cm4] Cortex-M4 r0p1 processor detected
    Info : [STM32H747XIXx.cm4] target has 6 breakpoints, 4 watchpoints
    [STM32H747XIXx.cm7] halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x08005860 msp: 0x20020000
    [STM32H747XIXx.cm4] halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x08103dc4 msp: 0x10048000
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    VisualGDB_OpenOCD_Ready
    Info : Listening on port 6666 for tcl connections
    Info : Listening on port 49513 for telnet connections
    Info : accepting 'gdb' connection on tcp/49515
    Error executing event gdb-attach on target STM32H747XIXx.cm7:
    target/stm32h7x.cfg:427: Error: invalid command name "gdb_attach_hook"
    at file "target/stm32h7x.cfg", line 427
    Info : Device: STM32H74x/75x
    Info : flash size probed value 2048k
    Info : STM32H7 flash has dual banks
    Info : Bank (0) size is 1024 kb, base address is 0x08000000
    Info : Device: STM32H74x/75x
    Info : flash size probed value 2048k
    Info : STM32H7 flash has dual banks
    Info : Bank (1) size is 1024 kb, base address is 0x08100000
    Info : New GDB Connection: 1, Target STM32H747XIXx.cm7, state: halted
    Warn : Prefer GDB command "target extended-remote :49515" instead of "target remote :49515"
    Error: Failed to read memory at 0x66c32214
    Error: Failed to read memory at 0x66c32214
    [STM32H747XIXx.cm7] halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x08005860 msp: 0x20020000
    [STM32H747XIXx.cm4] halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x08103dc4 msp: 0x10048000
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Unable to match requested speed 4000 kHz, using 3300 kHz
    Info : Device: STM32H74x/75x
    Info : flash size probed value 2048k
    Info : STM32H7 flash has dual banks
    Info : Bank (0) size is 1024 kb, base address is 0x08000000
    Info : Device: STM32H74x/75x
    Info : flash size probed value 2048k
    Info : STM32H7 flash has dual banks
    Info : Bank (1) size is 1024 kb, base address is 0x08100000
    Info : Device: STM32H74x/75x
    Warn : STM32H747XIXx.cm4 cannot read the flash size register
    Info : assuming 2048k flash
    Info : STM32H7 flash has dual banks
    Info : Bank (2) size is 1024 kb, base address is 0x08000000
    Info : Device: STM32H74x/75x
    Warn : STM32H747XIXx.cm4 cannot read the flash size register
    Info : assuming 2048k flash
    Info : STM32H7 flash has dual banks
    Info : Bank (3) size is 1024 kb, base address is 0x08100000
    Error: Failed to write memory at 0x90001600
    Error: Failed to write memory at 0x900055e0
    Error: Failed to read memory at 0x15503d22
    Error: Failed to read memory at 0x15503d22

     

    • This reply was modified 1 year ago by AndyCap.
    #34017
    support
    Keymaster

    Hi,

    No problem, please see the answers to your questions below:

    1. We have just rechecked the latest OpenOCD release from ST, and it looks like our build already has all the latest commits. The version number reported by the binary could be different due to the differences in build scripts, but otherwise it should be identical. However, the OpenOCD script files used to configure it could be different: STM32CubeIDE generates them dynamically based on some internal logic, and might insert some additional statements to handle QSPI. We would advice approaching it as follows:
      1. Make sure you can program and debug everything via command-line gdb + OpenOCD from STM32CubeIDE
      2. Make sure you can reproduce the problem with command-line gdb + OpenOCD from VisualGDB
      3. Try using setup (a) with binary from (b). It should normally still work as the binaries are identical.
      4. Inspect the OpenOCD scripts used by (a) and (b) looking for FLASH-related commands (flash <…>). Try copying them from the script file used in (a) to a copy of the script file used in (b).
      5. Once you get the modified script file working, you can configure VisualGDB to use it via VisualGDB Project Properties -> Debug Settings -> Advanced -> Command Line. You can use variables like $(ProjectDir) to avoid hardcoding paths there.
    2. If you would like to program the memory separately, you can add a command line for doing so to VisualGDB Project Properties -> Custom Debug Steps (to do it automatically), or Custom Shortcuts (to do it manually via a context menu command). Then, disable the regular memory programming via the Debug Settings page.
    3. VisualGDB always produces the ELF file and never deletes it. It normally has the same name as the .bin file, and no extension.
    4. If you have imported a STM32CubeIDE project, and are changing it, VisualGDB would check for changes when you open the VisualGDB project. You can force it to recheck it by closing and reopening a solution, or by reloading the project via context menu in Solution Explorer (not for all project types). Another option would be to use the advanced STM32CubeMX workflow – it internally uses the same importing logic, but nicely separates the STM32CubeMX-generated part from anything you would add later in Solution Explorer, and also has a context menu command to launch STM32CubeMX, and apply any changes it makes.
    5. If you absolutely want to use a custom OpenOCD executable, you can select “Custom GDB stub” in VisualGDB Project Properties -> Debug settings and specify the command line manually, however you will lose some advanced features like automatic substitution of USB serial numbers (for multiple ST-Link probes) and live memory reading. Using the regular OpenOCD method with a custom script should work much better.
    6. The STM32H747XI linker script you mentioned looks different from the default one. Please double-check where did it come from. If it’s located in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\2020.10\STM32H7xxxx\LinkerScripts, it was generated by us and could indicate a bug in our BSP generator. If it comes from %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\2020.10\VendorSamples, it was copied “as is” from the ST SDK, and could indicate a bug in the ST SDK that will likely be fixed in the next SDK version. In the latter case, please consider simply patching the file on your side as a temporary fix until ST fixes it properly and we release an updated BSP with the latest patches.
    #34021
    AndyCap
    Participant

    Thanks very much for the detailed steps.

    I am stumbling on the “VisualGDB always produces an elf file and doesn’t delete it” bit though, as there is no elf file here 🙂

    I have attached a pdf file of the exact steps I have taken.

    Cheers

    Andy

     

    Attachments:
    You must be logged in to view attached files.
    #34023
    AndyCap
    Participant

    Ok ignore that, it is there but it doesn’t have a .elf extension!

    I will do the other tests and update the pdf file…

    #34024
    AndyCap
    Participant

    So, being very careful this time and clearing down the external flash between steps it looks like the STM32CubeIDE  version of OpenOCD is also not working correctly with the external flash. I was mistaken before when I thought this was working.

    If I use stink-gdb-server instead of openocd then everything works, external flash is written correctly.

    I will log an issue with them about this.

    I will also try this later with the 747 board as well.

    I will try getting stink-gdb-server working with VisualGDB…

    Cheers

    Andy

     

    Andy

     

     

     

    Attachments:
    You must be logged in to view attached files.
    #34026
    AndyCap
    Participant

    Now I have two debug configs:

    one using stlink-gdb-server which flashes internal and external

    one using the st openocd which flashes just internal.

    Works well for me, I will have a look at the 747 board tomorrow to see what is going on with that one…

    #34029
    support
    Keymaster

    Hi,

    Good to know it works. Let us know if you encounter further issues.

    #34032
    AndyCap
    Participant

    Hi,

    Just a follow up for the other STM32H747I-DISCO board incase anyone else has issues.

    The ST Openocd just does not work for this board you have to use ST-LINK_gdbserver.exe with a CustomGDB Stub.

    ST-LINK_gdbserver.exe will always flash the entire elf including external memory so if you have data in there that is not changing and you don’t want to wait ages for it to flash it every time you debug then it seems the way to do this is to strip the ext flash sections from the elf.

    I’m not sure I did this the best way but I create another Debug Config “DebugNoExt” and then use a custom debug step to strip the sections out of the elf. So now to do a full flash I choose “Debug” and to just flash the internal flash I use “DebugNoFlash”.

     

     

     

    • This reply was modified 12 months ago by AndyCap.
    Attachments:
    You must be logged in to view attached files.
    #34048
    support
    Keymaster

    Thanks for sharing this. BTW, we have published a tutorial showing how to use the ST-Link GDB server with VisualGDB here. We will watch for feedback on it and will consider creating an out-of-the-box debug package for it, similar to the OpenOCD one.

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