- supported chips
Frequent Asked Questions
The compiler does not work in MPLAB X.
I have problems using the compiler in MPLAB.
MPLAB does not supply source file path when starting the compiler, which means that the main C file and project files must reside on 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.
I get error message "Duplicate chip definition".
CC8E prints a Warning: "Data above address 0xFFFF is removed
in the COD file".
Solution 1: EEPROM and CONFIG data must be initialized manually when debugging. The application must not exceed 64k during debugging.
Solution 2: Start the MPASM assembler from inside the compiler as the last compilation step and use the assembler to generate the required COD or COFF file for debugging. The disadvantage is that debugging will use ASM mode only. However, the generated asm file is clearly readable and use C statements as comments. The generated ASM file can be adapted using the -A<xx> command line. Description on how to start MPASM is found in file LINKER.TXT and in the User's Manual. Alternatively adapt file RELOC.INC and remove the -rsc when using a single module.
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?
regsvr32 "C:\Program Files\MPLAB IDE\dlls\MPProgram.dll"
What does "WARNING: String limit (64) in COD file
I get "System error" when installing CC8E.
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):
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 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"?
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.
#pragma inlineMath 1
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' ".
How do I define the symbol ICD2_DEBUG ?
How do I define a new PICmicro?
How do I set up CC8E for MPLAB?
How do I use RAM banks?
Are there any known bugs?
The code generated for the switch statement looks wrong. Is it a bug?