Problems and solutions of debugger unable to connect to stm32

Many people have encountered the problem that debugger can not connect to STM32, whether it is j-link of IAR, ULINK of KEIL, or ST link of St. When this problem occurs, the debugging software will prompt that the connection with Cortex-M3 cannot be established, the program cannot be downloaded, or the device to be debugged cannot be found, etc.

Such problems occur when debugging modules that can run automatically without CPU intervention, or when debugging low-power mode programs.
The so-called "modules that can run automatically without CPU intervention" include: DMA, timer, ADC in continuous conversion mode, watchdog and other modules.
The root cause of this problem is:
1) The debugger needs to execute a program in RAM to write flash. If these auto running modules are not stopped, they will interfere with the execution of the program in RAM, resulting in download failure. For example, the DMA module is configured to copy a piece of data area continuously, and the debugger just needs to use the target area of DMA data transmission. At this time, the DMA operation will conflict with the debugger operation. For another example, if the watchdog is started and the hardware reset is not performed, the watchdog timeout will trigger the chip reset when the debugger needs to download the program next time, resulting in the download operation failure.

2) Low power consumption is realized by stopping the CPU clock. JTAG debugging is realized by communicating with the CPU. If the CPU clock is stopped, the debugger will lose communication with the CPU.
Some people say that "when I stop debugging, these modules have stopped running and should not interfere with subsequent debugging". This problem should be seen from several aspects:
1、 The debugger stops the running of the debugged program by stopping the clock of the CPU core. In fact, the hardware modules of the debugged chip have not been reset and they are still in the enabled state. Those modules that can run automatically are only in the suspended state. Once the clock is recovered, they will continue to run.
2、 At present, the commonly used debugging software, whether IAR EWARM or keil MDK, can not reset the hardware of the chip by the "reset" button on the debugging software interface. This "reset" button can only reset the software of the program in the chip, that is, to point the running pointer back to the address of the reset.
3、 The reset button on the board can be used to manually reset the hardware, so that all modules (including those capable of automatic operation) stop working and return to the reset state. But before the debugger needs to control the CPU, it needs to provide the clock for the CPU core, and then it needs a long period of time to do some initialization actions, and then it can take over the control of the CPU core. After the debugger provides the clock for the CPU core, the user program has started to run. If the user program initializes the hardware module and starts to run before the debugger takes over the control of the CPU core, there will still be conflicts with the debugger.
According to the above analysis, the key to solve this problem is that before the debugger takes over the control of the CPU core, all the operations that can automatically run the modules must be stopped to make them in a closed state. To achieve this, there are several schemes as follows:;
1) Every time you exit the debugging state, stop all modules, such as deinit() operation of the module.
2) At the beginning of the main() function, no matter what state each module is in, first execute the deinit() operation of the module, and then open the corresponding module at a later time in the program or when it is really needed. This ensures that the debugger has sufficient time to complete the initialization and download of the program when it just enters the debugging state. The deinit() operation of the module is performed first to close the modules that were opened by the last operation.
3) Adjust the setting of boot0 / boot1, change the startup mode to start from internal SRAM, and then combine with manual hardware reset. Since the state of BOOT0/BOOT1 is only meaningful when the hardware is reset, and the debugger does not make hardware reset, this setting will not affect the debugger's downloading program to Flash, nor will it affect the debugger in Flash.