STLink V3-mini can't program or debug anymore anymore

after a few month of not doing any daisy programming I came back to my project,

I have been having issues being able to connect the stlink v3mini … I did update all latest libDaisy and DaisySP git hub repros to the latests (and their submodules), updated my arm toolchain, brew update, all that stuff… not sure if there’s something in that which broke it for me…

I also can’t program the daisy with it, but I can still put the daisy in DFU mode to program it…
here’s some terminal output, any help or ideas of things to try would be appreciated,

thanks!

It looks like it finds the Cortex chip, but can’t read to some memory space.
I get the same output trying to program both my project and the example projects.

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
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 ’.
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 V3J7M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.208522
Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected
Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints
Error: read_memory: read at 0x5c001004 with width=32 and count=1 failed
Error executing event examine-end on target stm32h7x.cpu0:
/usr/local/share/openocd/scripts/target/stm32h7x.cfg:237: Error: read_memory: failed to read memory
in procedure ‘program’
in procedure ‘stm32h7x_dbgmcu_mmw’ called at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 170
in procedure ‘stm32h7x_mmw’ called at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 260
in procedure ‘stm32h7x_mrw’ called at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 242
at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 237
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Error: read_memory: read at 0x5c001004 with width=32 and count=1 failed
Error executing event examine-end on target stm32h7x.cpu0:
/usr/local/share/openocd/scripts/target/stm32h7x.cfg:237: Error: read_memory: failed to read memory
in procedure ‘program’
in procedure ‘ocd_process_reset’
in procedure ‘ocd_process_reset_inner’ called at file “embedded:startup.tcl”, line 1193
in procedure ‘stm32h7x_dbgmcu_mmw’ called at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 170
in procedure ‘stm32h7x_mmw’ called at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 260
in procedure ‘stm32h7x_mrw’ called at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 242
at file “/usr/local/share/openocd/scripts/target/stm32h7x.cfg”, line 237
Error: timed out while waiting for target halted
** Unable to reset target **
shutdown command invoked

After looking at another post, I found a reference to STLinkCube software
I get the following when trying to connect using that application… could It be either the daisy or the programmer ?

13:59:07 : Error: ST-LINK error (DEV_TARGET_HELD_UNDER_RESET)
13:59:31 : UR connection mode is defined with the HWrst reset mode
13:59:35 : ST-LINK SN : 001500325553500720393256
13:59:35 : ST-LINK FW : V3J13M4
13:59:35 : Board : STLINK-V3MINI
13:59:35 : Voltage : 3.20V
13:59:35 : Error: ST-LINK error (DEV_TARGET_HELD_UNDER_RESET)

Hi! I have been working through stuff that’s perhaps related, and was able to find a solution over on the daisy discord.

I’d re-post it here but it’s unlikely I’ll keep them both in sync, and I prefer discord.

Hope it’s helpful.

Have you considered how difficult it is to reference anything on Discord more than a few minutes (or maybe hours) away from RIGHT NOW?

Discord is about the worst way to create a usable base of knowledge, though it’s sometimes good to get an answer right now to a burning question that demands instant personal attention.

To be fair, it’s linking to a forum channel post, so it won’t get as buried as compared to text channels.

That said, OP may not have a Discord account and forum here can be good for archival reason (searchable by anyone via internet browser and Discord’s search feature can be tricky to use imo), so it may be good to continue the conversation over here or even just post the current solution/workaround. I would greatly appreciate it, thank you so much :slight_smile:

I was the one who suggested to @deathbots on Discord to make a post on this thread since another community member was encountering a similar issue here, and I should’ve been clearer with my suggestion.