3

I'd like to get a multi-core debugging running with my STLINK adapter. I've got experiences in debugging with other tools (e.g., uTrace/Trace32 from Lauterbach). Now, I'd like to setup a multi-core arrangement as a hobby project at home - where I don't have a uTrace but only different versions of the STLink (much cheaper). Sadly, I'm not experienced at all in using OpenOCD. Any help is highly appreciated!

What I did so far

  1. RTFM.1 I see many typical use cases in the manual, but not a systematic description on which commands include/require (which) sub-commands. This impedes recognizing the solution to my (exotic ?) use case.

  2. Setup a working single-core OpenOCD configuration:

    • The generated config file uses example OpenOCD script files from installation: stlink.cfg (interface: hla), stm32f1x.cfg(swj-dp.tcl, mem_helper.tcl)
    • That setup works nicely - but only with a single board/core...! Still, it shows that my STLINK and target boards are OK, and the tool versions can (in principle) communicate with each other.

  3. Inspected other OpenOCD example files among my STM32CubeIDE installation.

    stm32h7x_dual_core.cfg is made for the wrong µ-controller, but it includes a dual-core option. Inside, I found this warning:

    # Issue a warning when hla is used, and fallback to single core configuration
if { [set $_CHIPNAME.DUAL_CORE] && [using_hla] } {
    echo "Warning : hla does not support multicore debugging"
    set $_CHIPNAME.DUAL_CORE 0
}

    Hence, interface hla cannot be used for multi-core debug (as far as this comment is correct, and I understand it).

[EDIT]

Integration of the dual-core variants in the STM32H7 family is described here. Still, these controllers only comprise a single TAP in the JTAG chain, which allows access to several Access Ports (APs) at an internal bus behind it.

[/EDIT]

The following steps describe how I tried to get an STLINK/JTAG configuration running for a single board, with a different interface setting than hla.

  1. Look for other interface options in OpenOCD

    OpenOCD supports a number of different interfaces,

         **C:\Temp>** C:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_1.3.0.202002181050\tools\bin\openocd.exe -c "interface st-link" -c "transport list"
     Open On-Chip Debugger 0.10.0+dev-01193-g5ce997d (2020-02-20-10:57)
     Licensed under GNU GPL v2
     For bug reports, read
             http://openocd.org/doc/doxygen/bugs.html
     The following transports are available:
             jtag
             aice_jtag
             stlink_swd
             stlink_jtag
             swd
             stlink_swim
             hla_jtag
             hla_swd
     [...]

    but together with my STLINK, I'm getting interface-related error messages unless I choose an hla option or either of the following two:

    • stlink_swd - SWD won't support daisy chains, so that's not an option for me!

    • stlink_jtag - JTAG is what I'm looking for, but this doesn't seem to work:

      With the following minimal (?) script

          interface st-link
    transport select stlink_jtag

      I'm getting no connection but the following log (activating plenty of debug):

          Debug: 17 15 options.c:184 add_default_dirs(): bindir=/src/work/openocd/win32/build/bin
    Debug: 18 15 options.c:185 add_default_dirs(): pkgdatadir=/src/work/openocd/win32/build/share/openocd
    Debug: 19 15 options.c:186 add_default_dirs(): exepath=C:/ST/STM32CubeIDE_1.3.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.win32_1.3.0.202002181050/tools/bin
    Debug: 20 15 options.c:187 add_default_dirs(): bin2data=../share/openocd
    Debug: 21 15 configuration.c:42 add_script_search_dir(): adding C:\Users\x\AppData\Roaming/OpenOCD
    Debug: 22 15 configuration.c:42 add_script_search_dir(): adding C:/ST/STM32CubeIDE_1.3.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.win32_1.3.0.202002181050/tools/bin/../share/openocd/site
    Debug: 23 15 configuration.c:42 add_script_search_dir(): adding C:/ST/STM32CubeIDE_1.3.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.win32_1.3.0.202002181050/tools/bin/../share/openocd/scripts
    Debug: 24 15 configuration.c:97 find_file(): found openocd.cfg
    Debug: 25 15 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_interface st-link
    Debug: 26 15 command.c:143 script_debug(): command - interface ocd_interface st-link
    Debug: 28 15 command.c:364 register_command_handler(): registering 'ocd_st-link'...
    Debug: 29 15 command.c:364 register_command_handler(): registering 'ocd_st-link'...
    Debug: 30 15 command.c:364 register_command_handler(): registering 'ocd_st-link'...
    Debug: 31 15 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_transport select stlink_jtag
    Debug: 32 15 command.c:143 script_debug(): command - ocd_transport ocd_transport select stlink_jtag
    Debug: 33 15 adi_v5_stlink.c:223 stlink_jtag_select(): stlink_jtag_select()
    Debug: 34 15 command.c:364 register_command_handler(): registering 'ocd_stlink_dap'...
    User : 35 15 command.c:693 command_run_line(): stlink_jtag
    User : 36 15 command.c:695 command_run_line(): 
    Info : 37 15 server.c:311 add_service(): Listening on port 6666 for tcl connections
    Info : 38 15 server.c:311 add_service(): Listening on port 4444 for telnet connections
    Debug: 39 15 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_init
    Debug: 40 15 command.c:143 script_debug(): command - init ocd_init
    Debug: 42 15 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_target init
    Debug: 43 15 command.c:143 script_debug(): command - ocd_target ocd_target init
    Debug: 45 15 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_target names
    Debug: 46 15 command.c:143 script_debug(): command - ocd_target ocd_target names
    Debug: 47 15 target.c:1438 handle_target_init_command(): Initializing targets...
    Debug: 48 15 stlink_usb.c:3755 stlink_dap_init(): stlink_dap_init()
    Debug: 49 15 stlink_usb.c:2674 stlink_usb_open(): stlink_usb_open
    Debug: 50 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x3744 serial: 
    Debug: 51 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x3748 serial: 
    Debug: 52 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x374b serial: 
    Debug: 53 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x3752 serial: 
    Debug: 54 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x374d serial: 
    Debug: 55 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x374e serial: 
    Debug: 56 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x374f serial: 
    Debug: 57 15 stlink_usb.c:2688 stlink_usb_open(): transport: 2 vid: 0x0483 pid: 0x3753 serial: 
    Info : 58 46 stlink_usb.c:1000 stlink_usb_version(): STLINK V3J6M2B4S1 (API v3) VID:PID 0483:374F
    Info : 59 46 stlink_usb.c:2810 stlink_usb_open(): using stlink api v3
    Debug: 60 46 stlink_usb.c:1230 stlink_exit_mode(): MODE: 0x01
    Debug: 61 46 stlink_usb.c:1278 stlink_usb_init_mode(): MODE: 0x01
    Info : 62 46 stlink_usb.c:1032 stlink_usb_check_voltage(): Target voltage: 3.278671
    Debug: 63 46 stlink_usb.c:1303 stlink_usb_init_mode(): MODE: 0x01
    Debug: 64 46 stlink_usb.c:1130 stlink_usb_mode_enter(): stlink_usb_mode_enter(JTAG)
    Debug: 65 46 stlink_usb.c:740 stlink_usb_error_check(): UNKNOWN_JTAG_CHAIN
    Error: 66 46 stlink_usb.c:2819 stlink_usb_open(): init mode failed (unable to connect to the target)
    Debug: 67 46 stlink_usb.c:1230 stlink_exit_mode(): MODE: 0x01
    Debug: 68 46 command.c:642 run_command(): Command failed with error code -4
    User : 69 46 command.c:705 command_run_line():

  2. Check the OpenOCD mailing list archives.

    There are some hints that multicore-JTAG+STLINK hasn't been supported in earlier OpenOCD revisions, but there have been some (preliminary?) changes about STLINK driver code in OpenOCD that I don't understand. Therefore, I'm still wondering which is the current status.

The Question

Does anybody know if OpenOCD supports JTAG through STLINK at all, or if I'm trying in vain? Do I have to add the correct JTAG chain/TAP/target definitions to get rid of the basic error messages, or is it pointless to try further?

Details - I'm using the following tool versions:

  • STM32CubeIDE for Windows, Version: 1.3.1 (Build: 6291_20200406_0752 (UTC)), including
  • OpenOCD, Version 0.10.0+dev-01193-g5ce997d (2020-02-20-10:57)
  • STLINK-V3SET (Info : STLINK V3J6M2B4S1 (API v3) VID:PID 0483:374F)
  • Target boards: 2x MCBSTM32, including STM32F103RB (With nucleo boards (STM32F4/STM32L4) I could try the same - but I think this is not the point).

1 "OpenOCD User’s Guide", 0.10.0+dev, STM, 20 February 2020 (st-openocd.pdf, part of STM32CubeIDE installation)

HelpingHand
  • 1,294
  • 11
  • 27
  • PS: I would have liked to add a tag "stlink" or similar. This doesn't exist (in contrast to [tag:segger-jlink] and [tag:lauterbach]). My reputation does no allow me to create/propose one. What do the more experienced users think? Do you agree to create it? – HelpingHand Apr 22 '20 at 17:59
  • 1
    IMO (very personal opinion) openOCD is not very solution in this case. I prefer JLinkserver. If it is hobby/educational project you can use J-Link EDU or Jlink mini. I though that stlink V3 will be much better and faster. But it is IMO not. – 0___________ Apr 22 '20 at 18:12
  • @P__J__ - Thanks for sharing your opinion. I've read similar opinions in other posts related to stlink yet (but not before I chose to spend my money on an stlink-V3...). The stlink adapters are a bit cheaper than the J-Links (unless we compare stlink-V3 to J-link EDU mini), so I decided to follow the issue a bit further in order to check for a lowest-cost solution. – HelpingHand Apr 22 '20 at 18:39
  • Nobody wants the bounty ??? – HelpingHand May 01 '20 at 20:55
  • 1
    read AN5286 ..... – 0___________ May 01 '20 at 21:03
  • Thanks for the hint, I think I already skimmed the AN once along my search. Which paragraph of the Application Note exactly do you mean? I believe that an STM32H7 dual-core is different to my setup as it has a shared JTAG TAP, and doesn't use a JTAG daisy chain (as I have to make for multiple single-core STM32 µCs). Instead, STM32H7 provides a single TAP/SWJ-DP with an internal bus leading to multiple APs behind it. The AN5286 doesn't tell anything about OpenOCD, and I couldn't extract any new info which I could transfer to my problem. – HelpingHand May 02 '20 at 12:32
  • For me, the issue now boils down to the questions **(1)** whether STLink supports *any* JTAG daisy-chains (beyond the usual internal chain of SWJ-DP and CoreSight TAPs that is build into every STM32), and **(2)** which of the OpenOCD drivers for STLink I have to use to run such a configuration. – HelpingHand May 02 '20 at 12:33
  • I afraid it will be difficult to answer. Most folks needing it use a bit more advanced ones (incuding me). I have one stlink v3 and I was disappointed (I think hardware is OK but software is not) – 0___________ May 02 '20 at 13:15
  • @P__J__ - Then you have the same impression about stlink-V3 driver/firmware I received during the last week. I haven't found a definitive answer looking around by myself, and one week of bounty passing by without any solution attempt is another hint that I should have better bought a j-link or so. When corona is over, I might meet some FAEs again (in 2021 or so?) - maybe anybody of them can tell me. *Sigh.* // Thanks for thinking it through anyway. – HelpingHand May 02 '20 at 15:31
  • problems with almost everything - but for professional use lack of reliable RTOS aware debugging is the worst. It is very slow (not they use very fast and powerful F7 uC but nothing has changed) those I2C SPi etc bridges are not very usable and IMO pointless. If I need something like this I will use something more specialized, – 0___________ May 02 '20 at 15:43
  • I believe the I2C and SPI bridges have only been added to build a bridge to their ready-to-use (or ready-to-throw?) bootloader, which might help those who have to use a noisy board connection that hardly allows JTAG/SWD. This belief keeps me from being dissapointed from the bridge features. The UART bridge works quite well. I wondering if I should give CMSIS-DAP a try, but I heard that it is also pretty slow. – HelpingHand May 02 '20 at 15:49
  • 1
    UART bridge it is something very standard. But I would not say that it works OK. It just works. *`I wondering if I should give CMSIS-DAP a try`* but only not HID implementation. HID is very slow and HID implementation is just unbelivable slow – 0___________ May 02 '20 at 17:12

1 Answers1

1

Probably a bit late but:

From UM2448 "The STLINK-V3SET does not support the chaining of devices in JTAG (daisy chain).

C.Hay
  • 36
  • 4
  • Not late at all - I didn't find any statement as clear as this in the meantime. But to advance, I bought a J-Link in the meantime, which arrived just last week :-). – HelpingHand Sep 04 '20 at 11:11