ST-Link-V3 on MacBook Pro M2 running Sonoma 14.4 only works through hub

[steezeman]

I am running a 16" M2 Pro MacBook with Sonoma 14.4.1. I am able to connect to the target and start the program + debug sequence, but when the debugger attempts to erase the memory, it halts (solid green light) and throws errors:

• failed to erase memory
• Stm32Device::clearPendingDebugEvents(): CTI check failed

This happens on my custom HW as well as on an unmodified Nucleo-144 H755.

There is a workaround - run the debugger through a USB hub. I have an Anker USB 3.0 hub that connects to the USB-C port on the computer. The debugger does not work when directly connected to the MacBook via a high-quality USB-micro to USB-C cable. I tested several other cables with several adapters and all had the same result, so I know this is not the cable. I'd like to run the debugger directly to the laptop without needing a hub.

There's a possibility that Apple introduced a bug in Sonoma 14.4 that messed up USB devices, and there have been a few complaints about hubs *not* working. This is strange because it only works *with* a hub. One possibility is there might be some setting in libusb that isn't set correctly on the ST driver side?

This is the console log from the Nucleo H755 board:

ST-LINK_gdbserver -cp /opt/ST/STM32CubeCLT/STM32CubeProgrammer/bin -p 6605 -d -m 0 -t


STMicroelectronics ST-LINK GDB server. Version 7.5.0
Copyright (c) 2023, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 31
        Listen Port Number         : 6605
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

Info : default port : 7184
Info : Remote address: 127.0.0.1
Info : Remote address: 127.0.0.1
Info : STLINKV3 v3J12M3, PID 0x3754
COM frequency = 24000 kHz
Target connection mode: Default
Reading ROM table for AP 0 @0xe00fefd0
Hardware watchpoint supported by the target 
ST-LINK Firmware version : V3J12M3
Device ID: 0x450
PC: 0x800161c
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.28 V
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
SwvSrv state change: 0 -> 1
Waiting for connection on port 6606...
Waiting for debugger connection...
Waiting for connection on port 6605...
Accepted connection on port 6605...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 6605...
GDB session thread running
GdbSessionManager, session started: 1
Stm32Device, closeDevice() entry
GDB session, device event: 5
Stm32Device, pollAndNotify stopped
Stm32Device, closeDevice() exit
 ------ Switching to STM32CubeProgrammer ----- 
Error: recv returned 0. Remote side has closed gracefully. Good.
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.15.0                  
      -------------------------------------------------------------------



Log output file:   /tmp/STM32CubeProgrammer_I5eK9n.log
ST-Link Server is running on port : 7184
ST-LINK SN  : 004700403532511031333430
ST-LINK FW  : V3J12M3
Info : Remote address: 127.0.0.1
Info : STLINKV3 v3J12M3, PID 0x3754
Error: recv returned 0. Remote side has closed gracefully. Good.
Info : Remote address: 127.0.0.1
Info : STLINKV3 v3J12M3, PID 0x3754
Info : default port : 7184
Info : Remote address: 127.0.0.1
Info : stlinkserver already running, exit
Info : default port : 7184
Info : Remote address: 127.0.0.1
Info : stlinkserver already running, exit
Board       : NUCLEO-H755ZI-Q
Voltage     : 3.27V
SWD freq    : 8000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M7/M4
BL Version  : 0x91



Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_luLnbF.srec
  File          : ST-LINK_GDB_server_luLnbF.srec
  Size          : 101.12 KB 
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Error: failed to erase memory


Error: failed to erase memory
Encountered Error when opening /opt/ST/STM32CubeCLT/STM32CubeProgrammer/bin/STM32_Programmer_CLI
 ------ Switching context ----- 
Error in STM32CubeProgrammer
Stm32Device::clearPendingDebugEvents(): CTI check failed
GDB session, device event: 3
Error in executing 'detach' command ... 
GDB session terminated: Client connection lost
GdbSessionManager, session terminated: 1
GdbSrv, last session terminated, signal dispose
Stopping port 6605
Error: recv returned 0. Remote side has closed gracefully. Good.
com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: Error finishing flash operation
Debugger disconnected

Process finished with exit code 0
Cleanup session: 1
GDB session disposed: 1
GDB Server stopped, exit code 137

[STOne-32]

Dear @steezeman ,

Thank you very much for sharing the analysis. Indeed we completely confirm the workaround and is valid to have a USB Hub between the Host Mac controller and STLink3 or use STLink2 .  The root cause issue is coming from very low level hardware signaling incompatibility between our emebbed High speed USB Phy and a TI host controller Phy used on these machines . Our teams will be back with a corrective action and information on the workarounds as you proposed. Thank you again for the valuable feedback, much appreciated. 

STOne-32

[akshatb]

Hi @STOne-32 are there any further developments on this?

We are building a new device for a University course and have gone with STLink-V3MODS. It would be great if we don't have to supply USB hubs to all the students using M2/M3 computers.

If there is any beta firmware to trial, I am happy to give that a go.

Thanks