µVISION DEBUGGER: Cannot set breakpoints or step through C/C++ code
Information in this knowledgebase article applies to:
When starting a debug session in µVision, I cannot step through
source code. Breakpoints are lost. It seems like only the Disassembly
window contains recognizable information.
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 armcc, and -g in
armclang. 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
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
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 armcc) or to speed up
execution time (-O3 in armcc). 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:
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
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:
DEBUGGER: SOURCE LEVEL DEBUGGING OF LIBRARY CODE). With
other images executing earlier, it may take extra time for
the device to reach 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
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
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
The following Discussion
Forum threads may provide information related to this topic.
Nordic FORUM THREADS
Last Reviewed: Friday, April 13, 2018