Debugger not working after upgrade to STM32CubeIDE 1.1.0

same here with STM32F405RGT6.

-- EDIT --

looking at the release note:

> ST-LINK GDB-server does not work properly with the macOS® version of STM32CubeIDE. The use of OpenOCD or J-Link is required.

-- EDIT SOLVED! --

installed openocd:

brew install openocd

then in IDE:

Debug Configurations -> Debug -> Debug Probe to ST-LINK (OpenOCD)

had also to enable sw reset:

Show generator options... -> Reset Mode -> Software system reset

looks everything is now working as expected!

It works now, following the suggestion of Massimiliano. Thank you.

thankyou for this solution! I would not recommend upgrading from 1.0.1 to 1.1 for mac users - it's been a frustrating evening!

• first, the ide hangs when you import your old projects from 1.0.1. This is mentioned in the release notes, but no workaround. so I rebuilt my project by hand
• then, it fails to flash the board when you hit debug...

so I reinstalled STM32CubeIDE fresh. My mac refused to open the .app saying it was 'damaged, move to trash?'. The fix was (after googling) to run sudo xattr -cr /Applications/STM32CubeIDE.app and this allowed the freshly installed IDE to start

• but we still have the flash problem... back to google, and we find this answer! thanks to this answer above there is a workaround!

I have a working board again, but I think these issues make the experience of upgrading or installing 1.1 a bit of a pain. I'm mostly writing this in case anyone experiences any of those same issues.

Looking forward to the next patch of the ide. thanks for the awesome platform, despite its mac-y release issues.

Incredible they let the product out with such problems. Not professional at all.

I think STM32CubeIDE is a great "all-in-one" tool to start developing your application upon the STM32 platform, but it is still "too young" and need to grow its stability. I hope this will happen in the next releases.

Another bug I found is this version is that seems it is unable to recognise my sources directory is under SVN versioning so the "Team" submenu in the project popup doesn't show anymore all SVN-related commands. For now I will use the command line to commit my changes.

The tools are based on very much mature tools and standards. What happened on this release looks like a huge lack of quality testing. Might be planned and intentional, don't know, i certainly do not intend that they lack competence. All they did needs pretty good stack of capabilities.

Most problems are regressions, not youngness problems. Releasing with such a list of known problems and without clearly telling users before updating is very bad practice.

I experience the same problem. I use Windows 10.

Debug via built-in to the Discovery board ST-LINK stopped working. Advices on the forum didn't help. I press "Debug" and nothing happends, literally nothing - no message (even the shortest one), no log, no perspective change, nothing. Until the problem is solved I go back to 1.0.2. I hope it will help.

29 Jan 2020: I've had a VERY SIMILAR experience: I've been using STM32CubeIDE alongside the separate STM32CubeProgrammer for a couple of months. I'm using BluePills (STM32F103) with the ST-LINK V2 JTAG/SWD programmer / ICE.

All the Edit-and-Compile territory seems to work fine, the programmer is on the button, and I've managed to educate myself about the suite while writing / compiling / burning and running several test programs. I gather this tool was previously TrueStudio by Atollic (is that correct ?) and that ST acquired them to build this "in-house" suite.

So far so good. Getting DEBUG to behave took a while -- the ST-LINK I have is fine, never seems to cause issue --- but the full STLINK-with-GDBServer experience I found fails instantly when the GDB server insists on checking the "ID" on the STM32 chip on the board -- this differs by one digit on the BluePills from the supposed ID code - and the GDB server will have no more of it and exits. BUT, up to now - the second option -- "ST-LINK OpenOCD" -- worked FINE, as that check appeared not to be made, and the whole step-through-code / stop and review memory content process, all worked fine, I was even starting to learn some GDB commands, as you get a GDB console still (not quite clear how / this is some alternate incarnation of the GDB service presumably, not made clear in the docs). All of that WORKED FINE all yesterday until..... suddently it didn't. Now, NOTHING: No debug functionality at all: IDE behaves exactly as before, except, when I hit the final "Debug" button in the Debug_Configuration options panel, which previously launched two consoles, one STLINK and one GDB and set off the whole debug cycle....

- ABSOLUTELY NOTHING happens - as if I had not touched the mouse.  

So --- dug around looking at configs, could find nothing relevant.   Ran a  ps -ef | grep gdb   and could see no GDB server running....  even if I switch back to the "ST LINK - GDB Server" option for debug.  Something's not getting launched.  

Battled with this for an hour / finally UNINSTALLED the whole STM32CubeIDE in toto using synaptic:   REINSTALLED, all the way from the downloaded master script.

IDE back up..  EXACTLY THE SAME.  NO Debug functionality at all.     Test the ST LINK with CubeProgrammer --- works fine.  

ST --- this is BRAND NEW V 1.2.0 IDE ST: downloaded clean and new a few days back (was using 1.0.2 before).  What's going on ?  

I thought this code was mature ?

Now I'm reading up on OpenOCD to learn if I can do all this OUTSIDE your IDE.  

Might email this in to ST as well as the community to see what's afoot.  I have WORK to do ST:  tools should just work.   I've put my trust in you -- waiting to buy silicon for products -- can you sort this out please ?