Frequent Asked Questions

What about MPLAB X integration?

MPLAB X support is now available. Click here for a description.

I get error message "Duplicate chip definition".

It is not possible to use option -p in combination with #include CHIP_HEADER_FILE. It is recommended to use #pragma chip PICxxxxx or no chip definition in the source code to avoid this error. Only one chip definition is required. Option -p will override #pragma chip in the source code.

I get "System error" when installing CC8E.

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 CC8E folder and files have to be deleted manually to remove the compiler from the computer.

The address for some local variables and function parameters seem to be wrong. Why?

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.

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 CC8E 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 the Users Manual.

I got error message: "OPTION ERROR: Duplicate file name or option error 'Files\bknd\CC8E' ".

MPLAB supplies the include files path as a command line option to CC8E. However, you need to add doublequotes if the path name contains spaces. The string should look like "C:\Program Files\bknd\CC8E".

How do I define a new PICmicro?

CC8E 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.

How do I use RAM banks?

CC8E 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. CC8E will update the bank bits automatically (unless this updating is switched off).

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.

The code generated for the switch statement looks wrong. Is it a bug?

No, CC8E 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>:).

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"

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).

Build fails without any compiler error in the old MPLAB IDE.

The old MPLAB is sensitive to any moving or renaming the path to the MPLAB project files. The cure is to delete the MPLAB project files (*.mcp, *.mcs, *.mcw) and regenerate the project files by creating a new project in MPLAB. It is not required to move the source files.

I have problems using the compiler in the old MPLAB IDE.

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 recommended. This also applies when renaming the folder path.

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

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