for people that check this thread, it would be useful to clarify that the SWD link has several parts, the target, the host software, STLINK, gdbserver, the USB cable etc...
if the JTAG/SWD misbehaves it does not translate automatically it is the STLINK to blame.
So here I provide a hint:
try to disable your low power features or fancy debug gadgets when you have JTAG problems.
Reasoning:
most times bad CPU configuration will predictably kill your SWD but not always, it can also cause conflicts with the STM tools when they are attempting to access the CPU, this is even more obvious when the host cannot use "connect under reset" and that means the CPU is running normally while the SWD/JTAG is trying to identify the CPU, configure the debug subsystems and establish a debug link. if you mess with the CPU at the same time it may cause side effects on the debugger. if you are unlucky a JTAG crash will appear all of a sudden after many days of normal work. obviously "connect under reset" mitigates most problems, but is not always possible to use that.
it could also be that the CPU configuration is wrong, if it is unstable it is more likely that your software is interfering with the external equipment. this happens when:
1) you change the voltage supply configuration (some CPU have this), the supply can also be external as a switching or PMIC etc... so, this depends on your board + CPU
2) entering sleep or deep sleep may affect both JTAG/SWD and your trace tools like ITM/DWT. the same way it may affect any peripheral or driver until correctly configured
3) change CPU clock may interfere with ITM when deriving the clock from the CPU, this is CPU family dependent
4) some CPU have clock gating / low power modes / clock configurations that may affect debugging when not setup correctly, the SDK and manuals are not always explicitly telling you all side effects of some given configuration and most of the time you may need to guess or abstract the consequences on your debugging tools. thing is I have seen configurations that may cause bad behaviour in rare cases. for example you can turn off the clock for some components that are used by the STLINK during detection and initial configuration and this is totally undocumented, the fact is, I believe there are dozens of components the JTAG/SWD is accessing, some are part of the CPU, some are part of the SoC like DBGMCU.
5) when you activate the DWT, ITM or other CPU gadgets you shall be very careful on how you manipulate some control registers. an example would be:
CoreDebug->DEMCR = CoreDebug_DEMCR_TRCENA_Msk; // enable trace in core debug
DBGMCU->CR = 0x700000; // enable debug clocks
DWT->CYCCNT = 0; // reset the counter
DWT->CTRL = DWT_CTRL_CYCCNTENA_Msk; // enable the counter
should be instead:
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; // enable trace in core debug
DBGMCU->CR |= 0x700000; // enable debug clocks
DWT->CYCCNT = 0; // reset the counter
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; // enable the counter
note the operator |= instead of the = operator, these registers can be manipulated also by gdb
6) check the errata sheet for both core and STM :)
7) security features may change JTAG/SWD behaviour, your launch configuration may need to adapt. in some cases your bootloader should also help when SWD is allowed but running with security features on; for example you cannot connect under reset anymore, and other connections may have timing issues, so you may want to setup the cpu / clocks and then busy wait for the SWD to connect (with timeout). this delay helps to have a more stable connection, of course this is just theory, I am not recommending any specific processing here because the least you do the safer you are since any DBGMCU / DWT / CoreDebug etc... register access increase the chance of STLINK conflict.
8 ) you are hitting a UNPREDICTABLE configuration or condition because of a driver bug. usually if you do your own driver you must read carefully the manual and understand how to process registers. this also applies to the Cortex-M which has it's own manual and most people don't even read. I suspect not even those that produce well known public RTOS as I have spotted bugs on those too. beware that most online software are not a very good reference. if you mess with clock is very likely you want to use the SDK, clock handling are a minefield of these conditions.
9) GPIO incorrect or unsafe config manipulation even if it is temporary or done just during init. also clock disable of the GPIO (usually port A and B) may also affect, so if you reference count your port usage just remember to include JTAG/SWD pins or you may end up disabling clocks too soon.
GPIO init from STM32CubeMX seems fine; some people find it a bit simplistic and end up doing their own gpio driver.
I am sure there are more, is impossible to do an exhaustive list as there are many CPU families and each may have important differences. but you got the idea, there are several things that are user responsibility.
I am quite sure that clock, power and CPU configurations are just the most obvious causes (on the firmware side) of your JTAG malfunction.
it can also be a bad solder, bad connector, bad flat, bad STLINK, bad driver, bad laptop, bad USB cable / USB hub / USB port. once you checked everything it is likely your JTAG will behave. once you have done these you may want to investigate the gdbserver too as ArnoutDekimo pointed out it can also be a weak point in the link.
in the meantime we hope ST will keep working on their STLINK and improve the reliability and user messages, it is known far from trivial to achieve a high quality SWD gadget that support all modern CPUs.
I keep using the ARM toolchain gdb as it is slightly more reliable with the disassembly view for unknown reasons.
