If you are attempting to debug a project that you have imported from the STM32CubeIDE, be aware that the STM-32 code generator may include a function call that disables the SWD debug functionality, which not only prevents debugging, but also prevents the embeetle IDE from flashing new code to the STM-32 target using openocd.
For the STM-32F1 series, the file stm32f1xx_hal_msp.c may contain a function call to __HAL_AFIO_REMAP_SWJ_DISABLE() - if it does, just comment this line out, and debugging will once again be possible.
The embeetle example project “blue-pill” has this function call present, so you will want to comment out the SWJ_DISABLE function call if you intend to try debugging.
If you have already compiled and flashed that example project to your blue pill, you can use the STM32CubeProgrammer application to erase the STM-32 and start over.
I think you are saying that “__HAL_AFIO_REMAP_SWJ_DISABLE()” is a function that disables the SWD interface. And therefore makes flashing impossible.
But you are also saying that STM32CubeProgrammer can still flash the chip.
Do you know what the STM32CubeProgrammer does differently to OpenOCD ?
Yes, the function “__HAL_AFIO_REMAP_SWJ_DISABLE()” repurposes the SWCLK and SWDIO debugging pins as GPIO pins. After that function executes, a debugger can no longer connect to the STM-32 on-chip debug hardware, until the chip is reset or power cycled.
The openocd file openocd_chip.cfg that’s part of the embeetle blue-pill example project has the statement:
reset_config srst_only
on line 3 of the script file. This doesn’t appear to cause the NRST signal from my debugger probe to toggle. The openocd documentation about this reset_config option is a bit thin, so it’s not clear to me what that reset_config option is supposed to do.
I have found that replacing line 3 of the openocd_chip.cfg file with:
reset_config srst_only srst_nogate connect_assert_srst
will toggle the NRST signal, and allow programming and verification of the STM-32 to occur. The programming script unfortunately still reports exit code ‘2’ which is not very comforting, however. After the application starts and the debug disable function is executed, debugging capability is still not going to be available. Ultimately, I’ve found that simply commenting out the function “__HAL_AFIO_REMAP_SWJ_DISABLE()” is the preferred option for me.
A second problem can occur if one is using an inexpensive STLINK V2 clone. Many of these debug modules have an error with the routing of the NRST signal from the internal microcontroller. The error can be corrected with a trace cut and wire jumper, but the modification requires some delicate soldering, so many people may try to use the module as-is. If the debug disable function is commented out, then an unmodified debugger module can still connect to the target, reset it, and program the application via the STM-32 on-chip debug hardware.