The first problem I had was that mikroC v4.6.0 kept crashing on my Windows 7 64bit development system every time is was closed. It would also crash every time I tried to change any settings. After a bit of playing around I found out that Windows wasn’t allowing mikroC to change files in the program directory. I had to manually change the file permissions on the directory which is “C:\Program Files\mikroC PRO for PIC” on my machine. I changed the directory permissions by right clicking the directory, selecting Properties->Security and then editing the permissions so that Users can modify as well as write files. That fixed the crashing problem and now I could change program settings.
I didn’t notice the next problem until I had been struggling to debug a simple section of code that wasn’t working properly. I was driving me nuts because variables were changing in memory contrary to the flow in the code. After a lot of time reviewing the assembler outputs from the compiler I realized that the compiler was using the some of the reserved memory locations saved for the ICD3 debugger by MPLAB. The fix for this is to modify the linker file that comes with mikroC for the PIC16F887. The resources needed for the ICD3 debugger can be found in the MPLAB help files.
This is section in the original linker file (C:\Program Files\mikroC PRO for PIC\defs\P16F887.mlk) that I changed:
<ICD> <HWBRKPNO>1</HWBRKPNO> <START_ADDR>0x1E00</START_ADDR> <BADRAM> <MIN_ADDR>0x1E3</MIN_ADDR> <MAX_ADDR>0x01EF</MAX_ADDR> </BADRAM> <BADRAM> <MIN_ADDR>0x7F</MIN_ADDR> <MAX_ADDR>0x7F</MAX_ADDR> </BADRAM> </ICD>
I changed it to:
<ICD> <HWBRKPNO>1</HWBRKPNO> <START_ADDR>0x1E00</START_ADDR> <BADRAM> <MIN_ADDR>0x1E5</MIN_ADDR> <MAX_ADDR>0x01F0</MAX_ADDR> </BADRAM> <BADRAM> <MIN_ADDR>0x70</MIN_ADDR> <MAX_ADDR>0x70</MAX_ADDR> </BADRAM> <BADRAM> <MIN_ADDR>0xF0</MIN_ADDR> <MAX_ADDR>0xF0</MAX_ADDR> </BADRAM> <BADRAM> <MIN_ADDR>0x170</MIN_ADDR> <MAX_ADDR>0x170</MAX_ADDR> </BADRAM> </ICD>
Recompiling the project with the new linker file fixed my random variables changing problem while debugging. This was a tough one to figure out.
One final note about the mikroC compiler that wasn’t obvious to me when I first started to use it: It doesn’t use a stack for local function variables. This behaviour confused me at first because it’s contrary to how other compilers work, but maybe it’s necessary to deal with the PIC16F architecture which definitely isn’t C compiler friendly. It instead declares all variables statically and will reuse the same memory locations for other variables as well. This means that it’s possible to have a whole bunch of variables using the same memory locations in the chip since only 1 variable it active at a time. It also makes finding your local funtion variables difficult. If you can’t find your variable in the MPLAB Watch window symbol list, open the list file (*.lst) where the hex file is and search for “