µVISION DEBUGGER: Cannot Set Breakpoints or Step Through C/C++ Code

Information in this knowledgebase article applies to:

• Keil MDK

QUESTION

When I start a debug session in µVision, I cannot step through source code. Breakpoints are lost. It seems like only the Disassembly window contains recognizable information. What is the reason for this?

ANSWER

There can be several causes for this situation. Below is a walkthrough of potential causes, with resolutions:

• Check if Debug Information is enabled. Exit debug mode. Go to Options for Target (blue wand icon) => Output tab => Debug Information. This option matches instructions to source code during a build by generating debug symbols. It is equivalent to the command line options -g or --debug in Arm Compiler 5, and -g in Arm Compiler 6. In GCC, "-gdwarf-2" is also supported by the µVision debugger. Rebuild the project, and re-enter debug mode. This setting is often disabled in production environments to decrease build times.

• Lower optimization level. At high optimizations, executed instructions are furthest separated from source, and limited debug information is available. Code may appear to jump around when trying to stepping through. Variables may update before/after related source code. Some variables may not even exist.

  Fewer lines of code are considered executable machine code, which limits where hardware breakpoints can be placed. When a line of source does not represent executable code, upon entering debug mode, an exclamation sign enclosed in a circle replaces the breakpoint in the Editor window. To lower this level, go to Options for Target => C/C++ tab => Optimization level. This setting is often raised in production environments to reduce code size (-O2 in Arm Compiler 5) or to speed up execution time (-O3 in Arm Compiler 5). Rebuild the project, and re-enter debug mode to see the difference.

• Debug information was not loaded into the µVision debugger. This procedure depends on the area of memory storing application code:
  • µVision DEBUGGER: Source Level Debug Does Not Work in Flash
  • µVision DEBUGGER: Breakpoints are not hit when debugging in RAM
  • µVision DEBUGGER: Breakpoints lost with several Applications
• Debug information loaded into the µVision debugger does not match the image downloaded into the target device. This can happen in the following situations:
  • Source code is edited in debug mode. This disrupts the consistency between debug information and the source. Breakpoints base themselves on the earlier version of code, and new code cannot be executed or stepped through. Exit debug mode, build project, and re-enter debug mode.
  • Target was not updated with new image, before opening a new debug session. Exit debug mode. To automate this, in Flash targets, go to Options for Target => Utilities and enable Update Target before Debugging. If multiple instances of the IDE are using the same debug adapter to connect to the same device, force an update by using the LOAD button.

  • Debugging a different memory area. Devices can often boot from different areas of memory based on a bootloader or a separate library. A board's jumper configuration may control the boot process. Check if the addresses listed in the Disassembly window match the target's memory map. Exit debug mode. Use Options for Target => Target tab to view the memory areas intended to be used. For advanced users, go to Linker tab, and view the scatter file.

    Check if setting breakpoints in the Disassembly window works OK. Some types of faults may encourage users to jump to odd-numbered addresses. If this is true, jump back to even-numbered addresses by right-clicking in Disassembly Window, and select Show Disassembly at Address.... Remember to precede addresses with "0x". Users should be able to set hardware breakpoints in this window, at even-numbered addresses. A µVision project may lack access to another image or a library (libraries with source code can be added: µVision DEBUGGER: Source Level Debugging of Library Code). With other images executing earlier, it may take extra time for the device to reach the application code.

  • Cache Code: In Options for Target => Debug tab => Settings, check under "Cache Settings". See if the cache code option is enabled. If the program modifies itself or is otherwise overwritten, disable this option to read instructions from the target memory.
  • Download was unsuccessful, but was reported as OK. You can verify downloads at two different stages by enabling Options for Target => Utilities => Settings => Flash Download tab => Enable Verify, and enabling Options for Target => Debug => Settings => Debug tab => Verify Code Download.
• Secure/Non-secure access: For cores implementing ARMv8-M architecture (ex. Cortex-M23, Cortex-M33), if user only has access to the non-secure debug information, breakpoints set in secure code will not be recognized. In debug mode, if the core enters secure side, and debug information is loaded into µVision IDE, for both secure and non-secure images, then setting either secure or non-secure breakpoints will be effective and viewable. To learn more, view the application note, Using TrustZone on ARMv8-M.
• While virtualization of the Windows OS is not officially supported by MDK-ARM, it has been reported that running Parallels on a MAC can also cause this issue. due to an incompatibility related to UNC paths. With this type of issue, user could set breakpoints in startup files and pack-related files, but not the main source code groups. Mapping a directory path ("\\home\user_name") to a mapped network drive, closing the project, and re-opening the project from the mapped drive, is known to resolve the issue. But user should contact Parallels support and community to learn more about the best possible solution.
• Evaluation versions may also reach the 32KB limit when opening a debug session. After a notification message at the start, a restricted version can show this behavior. Use the one-time 7-day trial of MDK-Professional, or compare MDK editions and contact our sales team for a quote.

Tip: To debug startup code, users can do the following:

• Flash targets: Go to Options for Target => Debug tab => Disable "Run to main".
• RAM targets: In the initialization file, there is a line "g, main". Comment out this line to start debugging at the start of an image.

STATUS

• With a ST-Device and ST-Link selected install MDK5.27 or newer

MORE INFORMATION

• Refer to Breakpoints Window in the µVision User's Guide.

SEE ALSO

• ARM: Application Builds Without Error, But Does Not Run
• µVision DEBUGGER: Can't Set C Code Breakpoints Using Windows on a Mac
• µVision DEBUGGER: Problems to debug/simulate NXP Kinetis devices
• µVision DEBUGGER: Download to Flash vs. Update Target Options

FORUM THREADS

The following Discussion Forum threads may provide information related to this topic.

• µVision4: can debug in disassembly window but not source code windows
• Can't insert breakpoints by button and in C

Nordic FORUM THREADS

• Debug Session Doesn't Stop At Main For example, this can occur if no softdevice (or if a different softdevice library than the application code is designed for) is loaded into the target.
• Bootloader Debugging
• Cant Halt Processor On Keil Debug

Last Reviewed: Friday, December 11, 2020