Click the above 
“Chuangxue Electronics” to follow and easily learn electronic knowledge.
In the debugging of STM32 microcontrollers, a series of issues may arise. This article mainly introduces the possible problems encountered during STM32 debugging and their corresponding solutions.
1. After setting the type of emulator in the “Debug Tab”, the prompt “No ULINK Device found.” appears when downloading the program.
Solution: Keil MDK defaults to using the ULINK emulator to download the program. Change the emulator used for programming to the corresponding type in the “Utilities Tab”.
2. The following message appears when compiling the project:
main.axf: Error: L6218E: Undefined symbol __BASEPRICONFIG (referred from stm32f10x_nvic.o).
main.axf: Error: L6218E: Undefined symbol __GetBASEPRI (referred from stm32f10x_nvic.o).
main.axf: Error: L6218E: Undefined symbol __RESETFAULTMASK (referred from stm32f10x_nvic.o).
main.axf: Error: L6218E: Undefined symbol __RESETPRIMASK (referred from stm32f10x_nvic.o).
main.axf: Error: L6218E: Undefined symbol __SETFAULTMASK (referred from stm32f10x_nvic.o).
main.axf: Error: L6218E: Undefined symbol __SETPRIMASK (referred from stm32f10x_nvic.o).
Solution: The project lacks the “cortexm3_macro.s” file. Add both cortexm3_macro.s and STM3210x.s to the project.
3. Issues and solutions when the debugger cannot connect to STM32.
Many people have encountered the issue of the debugger not being able to connect to STM32, whether it is IAR’s J-Link, Keil’s ULINK, or ST’s ST-Link. When this issue occurs, the debugging software prompts that it cannot establish a connection with Cortex-M3, cannot download the program, or cannot find the device to debug.
This problem occurs when debugging modules that can run automatically without CPU intervention, or when debugging low-power mode programs. Modules that can run automatically without CPU intervention include: DMA, timers, ADC in continuous conversion mode, watchdog, etc.
——————————————————————–
The root cause of this problem is:
1. The debugger needs to execute a program in RAM to perform flash erase operations. If these automatically running modules are not stopped, they will interfere with the program execution in RAM, causing the download to fail. For example, if the DMA module is configured to continuously copy a data area, and the debugger needs to use the target area for DMA data transfer, the DMA operation will conflict with the debugger’s operation. Additionally, if the watchdog is activated without performing a hardware reset, the next time the debugger needs to download the program, the watchdog timeout will trigger a chip reset, causing the download operation to fail.
2. Low power consumption is achieved by stopping the CPU clock, while JTAG debugging is implemented through communication with the CPU. Stopping the CPU clock causes the debugger to lose communication with the CPU.
——————————————————————–
Some might say, “When I stop debugging, these modules have already stopped running, so they should not interfere with subsequent debugging.” This issue should be viewed from several angles:
1. The debugger stops the execution of the debugged program by stopping the CPU core clock. In fact, the hardware modules of the debugged chip are not reset; they remain enabled. Those modules that can run automatically are merely paused, and once the clock is restored, they will continue to run.
2. Currently, commonly used debugging software, whether it is IAR EWARM or Keil MDK, the “reset” button on the debugging software interface cannot perform a hardware reset on the chip. This “reset” button can only perform a software reset on the program inside the chip, which means redirecting the execution pointer to the reset address.
3. Using the reset button on the board can manually perform a hardware reset, stopping all modules (including those that can run automatically) and restoring them to the reset state. However, before the debugger can control the CPU, it must first provide a clock to the CPU core, and then take a considerable amount of time to perform some initialization actions before it can take over control of the CPU core. Once the debugger provides a clock to the CPU core, the user program begins to run. If the user program initializes the hardware modules and starts running before the debugger takes control of the CPU core, conflicts with the debugger will still occur.
——————————————————————–
Based on the above analysis, the key to solving this problem is to stop all automatically running modules before the debugger takes control of the CPU core, ensuring they are in the off state. This can be achieved through the following methods:
1. Each time you exit debug mode, first stop the operation of all modules, such as executing the DeInit() operation for that module.
2. At the beginning of the main() function, regardless of the state of each module, first execute the DeInit() operation for that module, and then enable the corresponding modules later in the program when truly needed. This ensures that the debugger has sufficient time to complete initialization and download operations as soon as it enters debug mode. The purpose of executing the DeInit() operation for that module first is to turn off the modules that were enabled in the previous operation.
3. Adjust the BOOT0/BOOT1 settings to change the startup mode to boot from internal SRAM, combined with a manual hardware reset. Since the state of BOOT0/BOOT1 is only meaningful during hardware reset, and the debugger does not perform hardware reset, this setting will not affect the debugger’s ability to download programs to Flash and will not affect debugging programs in Flash.
4. When debugging STM32 programs, some flags are unexpectedly cleared by the debugging software.
During debugging, using the register or memory display window of the debugging software makes it easy to check the status of peripheral registers.
Many friends have encountered the issue where certain flag bits do not change in the display window during single-step debugging, and when they should be set, the window shows 0. Many mistakenly believe this is a chip issue.
We know that many status register bits of STM32 peripherals can be cleared by reading certain registers (for example, many flag bits in I2C’s I2C_SR1). During debugging, whenever the program stops at a set breakpoint or single-step stop, the debugging software automatically reads all specified registers and memory contents and refreshes the window display. This read operation by the debugging software happens to clear those flag bits, causing the described phenomenon.
There are several simple ways to solve 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 before operations on these sensitive register bits to ensure that these register bits are not accidentally modified by the debugging software.
4. Feel free to add more suggestions.
5. When using peripherals of STM32, if the IO port is used for multiplexing functions, but the peripheral initialization is correct, the GPIO port initialization is correct, and the peripheral clock is enabled, yet the peripheral cannot operate normally.
The most crucial point that many users often overlook is that when a certain IO port is used as a peripheral interface, the clock for the IO port’s multiplexing function must be enabled. That is, when enabling the clock for the peripheral and IO, the following code needs to be executed:
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOx | RCC_APB2Periph_AFIO, ENABLE); /* GPIOx and AFIO clock enable */
x — corresponds to the GPIO port, such as: A, B, C, D, E.
When using, be sure to pay attention to this point!
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
==> Visit www.eeskill.com to learn more!