How can I solve the problem that the debugger cannot connect to stm32?

Many people have encountered the issue that the debugger cannot connect to stm32, whether it is the J-link of IAR, The ulink of Keil, or the St-link of St. When this problem occurs, the debugging software prompts that a connection to the Cortex-M3 cannot be established, prompts that the program cannot be downloaded, or prompts that the device to be debugged cannot be found.
This problem occurs 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, and watchdog modules in the Continuous Conversion Mode.



--------------------------------------------------------------------------------
The root cause of this problem is:
1. the debugger needs to execute a program in Ram to erase Flash files. If you do not stop these automatically running modules, they will interfere with the execution of the program in Ram, causing download failure. For example, if the DMA module is configured to copy a data area without stopping, and the debugger needs to use the target area of DMA data transmission, the DMA Operation will conflict with the operation of the debugger. For another example, if the watchdog is started without hardware reset, the chip reset will be triggered when the next time the debugger needs to download the program, leading to download failure.
2. Low Power Consumption is achieved by stopping the CPU clock. JTAG debugging is achieved by communicating with the CPU. If the CPU clock is stopped, the debugger will lose the communication with the CPU.
--------------------------------------------------------------------------------
Some people say that "when I stop debugging, these modules have stopped and should not interfere with subsequent debugging". This problem should be resolved from several aspects:
1. the debugger stops the running of the program to be debugged by stopping the clock of the CPU core. In fact, the hardware modules of the chip to be debugged are not reset and they are still in the enabling status, the modules that can run automatically are only paused. Once the clock is restored, they continue to run.
2. currently, common debugging software, whether IAR ewarm or Keil MDK, the "reset" button on the debugging software interface cannot reset the hardware on the chip, this "reset" button can only execute software reset for programs in the chip, that is, re-point the running pointer to the reset address.
3. Use the reset button on the board to manually reset the hardware so that all modules (including those that can run automatically) stop working and restore to the reset status. However, before the debugger needs to control the CPU, it must first provide a clock for the CPU core, and then perform initialization for a long period of time before taking over the control of the CPU core. After the debugger provides a clock for the CPU core, the user program starts to run. If the user program initializes the hardware module and starts running before the debugger takes control of the CPU core, it will still conflict with the debugger.
--------------------------------------------------------------------------------
According to the above analysis, the key to solving this problem is that before the debugger takes control of the CPU core, it is necessary to stop all operations that can automatically run modules so that they are in the off state, to achieve this, you can have the following solutions:
1. Stop running all modules every time you exit the debugging status, such as executing the deinit () Operation of the module.
2. when the main () function starts, the deinit () Operation of the module is executed no matter the status of each module, then enable the corresponding module at a later time in the program or when it is actually needed. This ensures that the debugger has enough time to initialize and download the program when it enters the debugging status. The purpose of the deinit () operation of this module is to disable the modules enabled in the previous operation.
3. Adjust the boot0/boot1 settings, change the startup mode to internal SRAM startup, and then combine manual hardware reset. Because the boot0/boot1 status only makes sense when the hardware is reset, And the debugger does not reset the hardware, this setting does not affect the debugger to download the program to flash, debugging programs in flash will not be affected.


When debugging the stm32 program, some flag spaces are accidentally cleared by the debugging software.
During the debugging process, you can use the registers or memory display window of the debugging software to conveniently view the status of the peripheral registers.
Many of my friends have encountered this problem: During single-step debugging, some changes to flag spaces cannot be seen in the display window. When setting these flag spaces, the window is displayed as 0. Many people mistakenly think this is a problem with the chip.
We know that many Status Register bits of stm32 Peripherals can be cleared by reading some registers (for example, many bits in i2c_sr1 of I2C). During the debugging process, when a program stops at a set breakpoint or in a single step, the debugging software automatically reads all the content in the specified register and memory, and refreshes the display in the window, the read operation of the debugging software removes the flag spaces, resulting in the phenomenon described above.
There are several simple solutions to this problem:
1. Close the register or memory display window.
2. Do Not Display these sensitive registers in the register or memory display window.
3. Do not place breakpoints in front of sensitive register bit operations to ensure that these register bit operations are not accidentally performed by the debugging software.

Turn stone brother

How can I solve the problem that the debugger cannot connect to stm32?