Frequent Asked Questions

1.  I have problems using the compiler on MPLAB version 6 and 7.
MPLAB does not always behave as expected. The installation steps described in compiler file INSTALL.TXT need to be followed carefully. The following details should also be checked:

a) After entering or changing path names for the language toolsuite ("Project->Select Language Toolsuite"), MPLAB may need to be closed and restarted before the newly entered names are used.

b) MPLAB does not supply source file path when starting the compiler, which means that the C files and project files must reside on the same folder.

c) The include files path $(INCDIR) found on "Project->Build Options->Project" need doublequotes ("...") if the path names contain spaces. Also, do not use a backslash+doublequote (\") at the end of the path name because the options forwarded to the compiler will not be right then.

d) Before using MPLINK in combination with the compiler, please read compiler file LINKER.TXT, line 485, "MPLAB SUPPORT". It is recommended to try the linker example found in LINKER.TXT first.

e) Copying the MPLAB project files to a folder different from the one where the project was created may cause problems. Copying the source files and creating a new project is probably better.

2.  MPLAB prints the error message "The format of the file C:..\..\myprogram.HEX can not be read or written because its extension was not recognized". How can it be solved?
It is required to run a command using Start->Run. Note that parts of the path may have to be changed ("Program Files") depending on the language on your computer. The command is:

  regsvr32 "C:\Program Files\MPLAB IDE\dlls\MPProgram.dll"

3.  What does "WARNING: String limit (64) in COD file exceeded" mean?
The COD file format has a weakness. The length of a file name including full path must not exceed 64 characters. This is often not enough when the project is located deeply in the folder structure. The cure is to move the project to a folder closer to the top (root).

4.  I get "System error" when installing CC5X.
System error is often caused by TMP/TEMP variable problems. The installation program read the TMP/TEMP environment variable during installation. The TMP (TEMP) variable should normally be defined. The failure could typically be caused by one of the following reasons:

1. The environment variable is not defined

2. The environment variable points to a non-existing folder/directory (wrong setup)

In a MSDOS window environment variables can be inspected by using command: SET

To inspect a environment variable TMP you can use: SET TMP

In Windows you can inspect environment variables from the following "path" (depends on the language on your computer):

Control Panel->System->Advanced->Environment Variables

IMPORTANT: If the path name of the environment variable use "extended" ASCII codes, then the encoding of these could be different in a MSDOS window and the remaining WINDOWS. An example of an extended ASCII character is 'ã'. An extended ASCII character could look correct, but if the encoding is different, then the path is wrong when programs try to use it.

The problem with different ASCII character encoding can be solved by setting the TMP (TEMP) environment variable to another folder, or updating the path (editing it). The compiler installation program will use TMP to store temporary files which are deleted after the installation. In addition, information about the installation is stored to allow automatic uninstall, and also previous installation overwriting when installing a new version. When this information is missing, the CC5X folder and files have to be deleted manually to remove the compiler from the computer.

5.  The address for some local variables and function parameters seem to be wrong.
The compiler allocates space for local variables and parameters at fixed static locations because a dynamic stack is too costly (much more code generated and slow program execution). Local variables and parameters may share the same static locations to achieve efficient and safe reuse of RAM space. However, local variables are not allocated if the function is not called. The valid call trees are from main() and the interrupt routine, either by a direct call or indirectly through another function.

The unallocated variables are truncated to the same location. When using command line option -V there will be a mark at the unallocated local variables (file <xxx>.VAR). By using the -wU command line option a warning is printed for each uncalled function.

The following pragma will remove all unused routines if placed in the beginning of the program:

 #pragma library 1

Also note that all extern functions are separate call trees when using relocatable assembly. This separate allocation requires more RAM space.

6.  How do I solve the error message "Shared function 'xxx' contains local variables or parameters"?
This problem is not easy. The basic issue is that CC5X maps the local variables to static global locations. The PICmicros does not have a hardware stack, and emulating a stack in software would slow down execution too much, and generate too much code.

Using static locations is fast and efficient. However, at interrupt, there may be a collision if the same routine is called (from main and interrupt) because the local variables and parameters could be overwritten causing wrong results in the calculation in main. The local variables could be saved at interrupt, but this is not implemented, and there could be many locations to save. There could be other solutions that could be managed by the compiler, but there seem to be many difficulties with all of them.

Some application writers use "interrupt driven processing" where the interrupt function become large and takes time to process. This kind of program structure easily runs into the above problem. Another way to write the application is to let the interrupt function finish as fast as possible and leave to processing to the main routine. This could be done by flags (bit variables) that are set in the interrupt routine, and read and cleared in the main program. This program structuring also makes it easier to ensure that interrupts are not lost because little time is spent in the interrupt routine.

SOLUTION 1:
The error message can be changed to a warning by the following pragma statement. Note that this means that the earlier mentioned local variable and parameter overwriting must be avoided by careful code writing.

 #pragma sharedAllocation

SOLUTION 2:
The safer method is to duplicate routines that are called from both main and interrupt. For math functions you could use type casts to ensure that another math routine is called, or inline math (integer math only) in the interrupt routine, and a math function in main.

#pragma inlineMath 1
a = b * c; // inline math (no call) if integer operation
#pragma inlineMath 0

Another challenge is 'const' data which use a common routine to read the data. A solution is to access const data from interrupt using the #pragma return[] array described in Chapter 9.2 in the Users Manual, and in file 'c-goto.txt'.

7.  I got error message: "OPTION ERROR: Duplicate file name or option error 'Files\bknd\CC5X' ".
MPLAB supplies the include files path as a command line option to CC5X. However, you need to add doublequotes if the path name contains spaces. The string should look like "C:\Program Files\bknd\CC5X".

8.  How do I define the symbol ICD2_DEBUG ?
This symbol needs to be defined before the chip header file is included and processed because the ICD2 reservations are found in this file. MPLAB supplies the chip definition as a command line option, and this means that CC5X will use automatic include on the chip header file. Any manual include of the chip header file must be removed when using MPLAB. The symbol needs to be defined as a command line option. This is done by selecting the menu item "Project->Build Options...->project" and then adding -DICD2_DEBUG in the "Additional Command-Line Options" field.

9.  Why does debugging not work in MPLAB 6.43 - 6.60?
MPLAB 6.43 - 6.60 have a weakness. The COD file is not loaded automatically compared to earlier MPLAB versions.

Solution 1: Modify the TLCC5X.INI file in the folder LegacyLanguageSuites found in the MPLAB installation folder, line 9, from "Target=HEX to "Target=COD". This also require using the -CC or -CA command line option at compilation, otherwise MPLAB will say "Build Failed".

Solution 2:  Select "File -> Import" after a compilation, then set the file type to "Debug Files (*.cof;*.cod)" and look up the newly generated COD file and click the "Open" button. Single step and breakpoints are then available. The "import file" procedure have to be repeated after a new compilation.

10.  How do I define a new PICmicro?
CC5X comes with a lot of header files. New header files can be downloaded from this site. Besides, existing header files can be modified to suit new PICmicro devices.

11.  How do I set up CC5X for MPLAB?
CC5X can be selected as a tool from MPLAB. A detailed description of how to do this is found in file INSTALL.TXT in the compiler package. This allows you to take advantage of the MPLAB editor and simulator, including the ability to go directly to compilation errors by point-and-click.

12.  How do I use code pages?
CC5X requires that you define which code page the functions should be located on. This is either done by a page type modifier or by #pragma codepage or #pragma location statements. CC5X will update the page bits automatically when a function is called (unless this updating is switched off).

13.  How do I use RAM banks?
CC5X need to know which RAM bank a variable should be located in. This is either done by a bank type modifier or by using #pragma rambank statements. Local variables and function parameters are also located this way. It is also possible to locate variables directly on an address. CC5X will update the bank bits automatically (unless this updating is switched off).

14.  Are there any known bugs?
The policy is to correct and document bugs as soon as they are reported. If the bug is serious enough, a new version will be released quite soon. This depends on how easy it is to find workarounds. The list of known bugs is available to users of the licensed editions.

15.  The code generated for the switch statement looks wrong.
CC5X generates compact code, and it is sometimes difficult to understand the logic at first sight. The switch statement use a series of XORLW instructions and the test value at each XORLW does not correspond to the C code statements (case <n>:).