A µVision error line is rarely the whole story. µVision is the IDE and build front end, so the diagnostic you see usually comes from a compiler, assembler, linker, or a project setting. What a message means depends on which tool produced it and which version you are running. The most reliable way to read it is to find the first meaningful message in the build output, identify the stage that raised it, and then follow it to a source line or a configuration option.
Start with the Build Output window and the build log
Keil’s µVision User’s Guide describes the Build Output window as the place where errors, warnings, and build messages appear during a build. The same guide notes that the build log records the build process and the software components it used, which makes it the best record when the window scrolls past the message you need. Read from the top of the first failing file, not from the bottom. The final status line is a summary, and it often reports a failure that started several steps earlier.
Two navigation habits save time. Double-clicking a highlighted message jumps to the responsible source line. The older µVision Version 4 brochure also describes selecting a highlighted message and pressing F1 for help. That shortcut is older UI guidance, so confirm it in your version before relying on it.
Build and Rebuild do different amounts of work
The User’s Guide states that the Rebuild command translates all source files regardless of modifications. The Build command translates only new or modified files and then links. The difference matters when you read a log. If you changed a global option that affects every file and then used Build, the log may not show every file being translated, so an error from a stale object can look unrelated to your change. When you suspect stale objects or a project-wide setting change, run Rebuild before concluding that the source is at fault.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
Identify the toolchain before you interpret the message
The same wording can come from different tools with different causes. Before you act on a message, record four facts:
- The compiler or assembler family, such as Arm Compiler 5, Arm Compiler 6 (armclang), or the legacy C51 tool chain with BL51.
- The exact tool version and whether it is the 32-bit or 64-bit installation.
- The build stage that printed the line: compile, assemble, or link.
- Whether the message names a source file, a memory range, a symbol, or a project option.
Keil’s support articles are written for particular toolchains and versions. Treat them as explanations of specific cases, not as a dictionary of every error code.
What the common messages mean
The examples below are documented cases. Each one is tied to the toolchain described, so check your own build log before applying the fix.
error: #5: cannot open source file …: No such file or directory
Keil’s build guide lists an incorrect default path as one cause. If the missing file is a header, a startup file, or a system file, the documented recommendation is to reselect the device in Project — Options for Target — Device. Do not assume that every missing-file error is solved this way. A project can also reference a file that really was removed or renamed, or it can have a wrong include or search path. Check the path the message names against the file system before changing the device.
Recommended Free Tools
*** Error: Referred Memory Range ‘ROM2’ is undefined.
This error means that a file or component is assigned to a memory range that the project does not define. Look at three places: the target memory definitions, the scatter file if you use one, and the settings for the specific file or component. The assignment that causes the problem may exist only at file or component level, so a correct target-level setting will not clear it. Keil notes that MDK version 5.24 or later can include the source filename in the message, which makes the offending file easier to find.
Xdata memory range out of bounds
The µVision target dialog expects a start address and a length, not a start and end address. Keil’s example illustrates the difference. For an XDATA region running from 0x8000 through 0xFFFF, the size to enter is 0x8000. Entering 0xFFFF as the size requests a range far larger than the device has. Keil says the same start-plus-length rule applies to CODE memory areas.
WARNING L2: REFERENCE MADE TO UNRESOLVED EXTERNAL. (BL51/C51)
An unresolved external means the linker cannot find a symbol that the code refers to. Keil’s documented example is the C runtime library routine ?C?ILDOPTR, which BL51 cannot locate. Start by checking whether the linker options contain NODEFAULTLIBRARY. That directive tells BL51 to ignore the standard C51 libraries, so the lookup fails if your code relies on them. If the library file was removed or corrupted, Keil suggests reinstalling the C51 tool package. This guidance applies to the legacy C51 toolchain. Do not assume that every L2 message from every linker has the same cause.
Target has no object modules (C51 example)
In Keil’s example, the project generates an assembler .SRC file but assembly of that file is disabled. The linker therefore receives no object file. You can fix this in one of two ways: disable generation of the SRC file, or enable both generation and assembly. Choose the option that matches what the project should do, because either change removes the mismatch.
Error: L6218E: Undefined symbol __aeabi_assert (Arm Compiler 5/6)
Keil says this message can appear when MicroLIB is selected. MicroLIB is a smaller, separate C library. It does not implement many functions that interact with an operating system, and assert is among them. The useful question is whether the project deliberately uses MicroLIB. If it does, either confirm that the code does not need the missing function, or switch to a library that provides it. This diagnosis applies to this symbol and this library choice. It does not explain other undefined symbols.
No License Checking Back-end Registered with id Keil (Arm Compiler 6.x)
Keil’s article describes this message for a 64-bit Arm Compiler 6.x installation integrated with µVision. Keil states that MDK licenses are supported by 32-bit compiler versions, not 64-bit ones, and recommends installing a supported 32-bit Arm Compiler version. Licensing and compatibility rules change between releases, so check the current compiler and license documentation before you choose a version.
FATAL ERROR 204: INVALID KEYWORD (C51/C166 linker control file)
In the documented case, a linker control file contains object-file entries and a TO output directive. µVision already supplies the project’s object list and output command, so the duplicated entries conflict with it. Keil’s guidance is that the control file should contain only linker directives. Remove the duplicated object and output entries and leave the rest of the file unchanged. This remedy is specific to the C51 and C166 linker context.
Build Target recompiles files that have not changed (legacy NOAMAKE)
Keil explains that the NOAMAKE or NOAM directive removes make information from the generated object files. Without that information, µVision may not recognize normal dependency and timestamp data, so it retranslates files that have not changed. In the documented legacy toolchain case, remove the directive from the source pragmas or from the relevant options.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsBest Value
- Used Book in Good Condition
Target not created and other downstream messages
A status such as “target not created” usually reports the outcome of the whole build. It rarely identifies the cause. When you see it, scroll up to the first compiler, assembler, or linker message. A missing object module, for example, can be the consequence of an earlier assembly setting, and a link failure can be the consequence of a missing library. Fix the first actionable error, then rebuild and see which later messages remain.
Comparing messages by stage and fix
| Message | Stage | Toolchain scope | First thing to check |
|---|---|---|---|
| cannot open source file | Compile or preprocess | General µVision project | Whether the named file exists, the default path, and the device selection in Options for Target |
| Referred Memory Range ‘ROM2’ is undefined | Project configuration | µVision with MDK | Memory definitions, scatter file, and file or component assignments |
| Xdata memory range out of bounds | Project configuration | Target dialog memory areas (CODE and XDATA) | Whether the size field holds a length rather than an end address |
| WARNING L2 unresolved external | Link | Legacy C51 with BL51 | NODEFAULTLIBRARY in linker options and the C51 tool package |
| Target has no object modules | Assemble or link input | Documented C51 example | SRC generation and assembly settings |
| L6218E undefined symbol __aeabi_assert | Link | Arm Compiler 5/6 with MicroLIB | Whether MicroLIB is intended and supports the function |
| No License Checking Back-end registered | Compiler startup | 64-bit Arm Compiler 6.x integrated with µVision | Whether a 32-bit compiler version is installed and licensed |
| FATAL ERROR 204: INVALID KEYWORD | Link | C51/C166 linker control file | Duplicate object and TO entries in the control file |
| Build recompiles unchanged files | Build dependency | Legacy toolchain with NOAMAKE | Whether NOAMAKE or NOAM appears in pragmas or options |
A practical triage sequence
- Run Rebuild if you changed project-wide options or suspect stale objects. Build alone may not translate every file.
- Open the Build Output window and the build log, and locate the first error, not the final status line.
- Note the tool that produced the message, its version, and whether it names a file, memory range, symbol, or option.
- Double-click the message to reach the source line, or check the named setting in the project options.
- Change one setting at a time, then rebuild and check whether the first message has gone or changed.
Where these explanations stop applying
- The examples above come from Keil’s documented cases. Other projects can produce the same text for different reasons.
- Several fixes depend on legacy toolchains, notably C51, BL51, and C166. Newer Arm Compiler projects may not use these directives or library paths.
- The licensing guidance for 64-bit Arm Compiler 6.x reflects the version Keil described. Confirm current compatibility before installing.
- The guidance on the F1 shortcut comes from an older brochure, so check it in your µVision version.
When two fixes seem possible, compare how each one changes the intended runtime library and the target memory map. A change that makes the error disappear can still alter how the program is linked.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
