Openocd OSX (M2) Fail

Troubleshooting and Support
43

Ok, I just tried the USB C version of the stlink. It doesn’t work either.

I’m on Mac OS Ventura 13.5.2 (22G91)

I am starting to wonder if a latest mac update broke things.

This is what GDB Server is telling me:

[2023-11-28T21:13:16.532Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to “DEBUG CONSOLE” to see GDB interactions.
openocd -c “gdb_port 50000” -c “tcl_port 50001” -c “telnet_port 50002” -s /Users/kshep/Dev/DaisySeedProjects/Software/GuitarPedal -f /Users/kshep/.vscode/extensions/marus25.cortex-debug-1.12.1/support/openocd-helpers.tcl -f interface/stlink.cfg -f target/stm32h7x.cfg -c init -c “reset init”
xPack Open On-Chip Debugger 0.12.0+dev-01312-g18281b0c4-dirty (2023-09-05-01:32)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
CDLiveWatchSetup
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select ’.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1800 kHz
Info : STLINK V3J8M3 (API v3) VID:PID 0483:3754
Info : Target voltage: 3.252337
Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected
Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 50000
Info : Listening on port 50000 for gdb connections
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000a00 msp: 0x20020000
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : accepting ‘gdb’ connection on tcp/50000
Info : Device: STM32H74x/75x
Info : flash size probed value 128k
Info : STM32H7 flash has a single bank
Info : Bank (0) size is 128 kb, base address is 0x08000000

This is where it hangs.

44

I’m pleased to finally see somebody using an M2 Mac, with some success.

I’m still really curious to find out if it’s an issue of M1 vs M2, or something else…

@kshep does it hang only when debugging, or also when just uploading?

45

yes very similar. I have also sometimes libusb error massages.
Just for the record: Im on Sonoma 14.1.1 (23B81)

46

Yeah, it was working beautifully for me on my M2 mac for at least a month. I really can’t think of anything that changed, figured my hw just went bad, which is why I ordered the newer USB C version recently, but since that doesn’t work too now, something else must be going on.

@tele_player Good question, the way I had been using it is by doing Function F5 in VSCode which simply compiles everything debug and launches the context debug stuff. How would I go about just trying to upload using the stlink

47 
⌘+P

type

task

and press spacebar once
choose from

build
build and upload
build and debug
etc

EDIT: what was your working OSX version before you’ve updated to Ventura?

48

I was on Ventura before, it was just a point release likely.

I’ve just upgraded to Sonoma, issue still persists. Continuing to troubleshoot.

1 Like
49

Update, I’m getting it to work inconsistently now, but only with a really simple program. I’m using the LibDaisy Seed example called “Bypass”. I modified it with my launch.json to make sure the debugger is setup properly.

The other thing I changed was this setting in my System Preferences / Security:

image
image1410×692 103 KB

I noticed it was always asking me to Allow this device if I plugged it in.

Now sometimes when I try to use the debugger it works, and I can step through code. However, even if I stop the debugged and try to launch it again 90% of the time it doesn’t work again until I go through some song and dance of quitting VSCode, unplugging the stlink, and restarting.

Also, task build and program doesn’t seem to work for me either. So it’s not just the debugger.

1 Like
50

can you please post your launch.json?

51

This is what my launch.json looks like:

{
  "configurations": [
    {
      "configFiles": [
        "interface/stlink.cfg",
        "target/stm32h7x.cfg"
      ],
      "cwd": "${workspaceFolder}",
      "debuggerArgs": [
        "-d",
        "${workspaceRoot}"
      ],
      "executable": "${workspaceRoot}/build/guitarpedal.elf",
      "interface": "swd",
      "name": "Cortex Debug",
      "openOCDLaunchCommands": [
        "init",
        "reset init"
      ],
      "preLaunchTask": "build_all_debug",
      "preRestartCommands": [
        "load",
        "enable breakpoint",
        "monitor reset"
      ],
      "request": "launch",
      "runToMain": true,
      "servertype": "openocd",
      "showDevDebugOutput": "parsed",
      "svdFile": "${workspaceRoot}/.vscode/STM32H750x.svd",
      "type": "cortex-debug",
      "liveWatch": {
        "enabled": true,
        "samplesPerSecond": 4
      }
    }
  ],
  "version": "0.2.0"
}
52

thanks!

this is my output so far:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
CDLiveWatchSetup
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select ’.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1800 kHz
Error: libusb_open() failed with LIBUSB_ERROR_OTHER
Error: open failed

So I can’t get it to work even a bit…

EDIT: so I’ve just read that libusb is a 21 years old project…

53

Yeah, I do think libusb is the issue. There are wacky issues with USB access and Android File Transfer under Ventura and later Mac OS too. A lot of them have wacky work arounds like disabling Dropbox or Google File Storage, or even quitting the preview app. I have a feeling it relies on libusb too. It’s super wonky.

I’m wondering how to tell which libusb my system is using.

I have a version of libusb at /usr/local/lib/libusb/ and one at /opt/homebrew/Cellar/libusb/ I wonder if it’s getting confused. Or if one of them is not compiled for the native m2 processor architecture.

54

what does

otool -L /opt/homebrew/bin/openocd

or wherever your openocd bin is…
prints out?

EDIT:

mine says:

/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib (compatibility version 4.0.0, current version 4.0.0)
55

image
image1656×212 155 KB

56

it’s ok if you just copy paste as text… :wink:
so your openocd is using @rpath/libusb-1.0.0.dylib

I’m using the same lib.

I’ve read that there are some issues with the libusb and ftdi lib

“The problem with the FTDI driver for Mac is that it has two ports and it “confuses” openocd, so u need to remove the driver (in memory) and load it again with certain parameters EVERY TIME YOU BOOT.”

perhaps there is something…

but I’M not able to follow the instructions since I don’t have the

com.FTDI.driver.FTDIUSBSerialDriver

on my system