Microchip Technology XC8 Standard Compiler (Workstation) SW006021-1 SW006021-1 User Manual

®

DS52053B-page 68

 2012 Microchip Technology Inc.

Finally, there are errors that do not relate to any particular line of code at all. An error 
in a compiler option or a linker error are examples of these. If the program defines too 
many variables, there is no one particular line of code that is at fault; the program as a 
whole uses too much data. Note that the name and line number of the last processed 
file and source may be printed in some situations even though that code is not the direct 
source of the error.

To determine the application that generated the error or warning, take a note of its 
unique number printed in the message, see Section 4.6.1 “Messaging Overview”, 
and check the message section of the manual, see Appendix B. “Error and Warning 
Messages”. At the top of each message description, on the right in brackets, is the 
name of the application that produced this message. Knowing the application that pro-
duced the error makes it easier to track down the problem. The compiler application 
names are indicated in 4.3 “The Compilation Sequence”. If you need to see the 
assembly code generated by the compiler, look in the assembly list file, see 
Section 6.6 “Assembly List Files”. For information on where the linker attempted to 
position objects, see the map file discussed in Section 7.4 “Map Files”.

Warnings indicate situations that could possibly lead to code failure. In many situations 
the code is valid and the warning is superfluous. Always check your code to confirm 
that it is not a possible source of error and in cases where this is so, there are several 
ways that warnings can be hidden.

• The warning level threshold can be adjusted so that only warnings of a certain 

importance are printed, see Section 4.6.5.1 “Disabling Messages”

• All warnings with a specified ID can be inhibited

• In some situations, a pragma can be used to inhibit a warning with a specified ID 

for certain lines of source code, see Section 5.14.4.11 “The #pragma warning 
Directive”.

Even if you have set up the TRIS register and written a value to the port, there are sev-
eral things that can prevent such a seemingly simple program from working.

• Make sure that the device’s configuration registers are set up correctly, see 

Section 5.3.5 “Configuration Bit Access”. Make sure that you explicitly specify 
every bit in these registers and don’t just leave them in their default state. All the 
configuration features are described in your device data sheet. If the configuration 
bits that specify the oscillator source are wrong, for example, the device clock 
may not even be running.

• If the internal oscillator is being used, in addition to configuration bits there may be 

SFRs you need to initialize to set the oscillator frequency and modes, see 
Section 5.3.6 “Using SFRs From C Code” and your device data sheet.

• Either turn off the watch dog timer in the configuration bits or clear the watch dog 

timer in your code (see Section Appendix A. “Library Functions”) so that the 
device does not reset. If the device is resetting, it may never reach the lines of 
code in your program that blink the LED. Turn off any other features that may 
cause device Reset until your test program is working.

• The device pins used by the port bits are often multiplexed with other peripherals. 

A pin might be connected to a bit in a port, or it might be an analog input, or it 
might the output of a comparator, for example. If the pin connected to your LED is 
not internally connected to the port you are using, then your LED will never oper-
ate as expected. The port function tables shown in your device data sheets will 
show other uses for each pin that will help you identify peripherals to investigate.