4.13x Compiler error causing compiler lock-up (SOLVED)

[benoitstjean]

I encountered a problem with compilers 4.130 to 4.132 (not sure about previous or higher version) where the compiler pops an error message saying a file is already in use. When this message appears, there's nothing else that can be done, not even saving your files. The compiler MUST be closed and no files can be saved.

Unfortunately, this issue would have easily been avoided if CCS would better document their stuff. I don't want to slam them because the compiler is nice and easy to use, their technical support is very fast in responding (one of the fastest I've seen), but unfortunately, their documentation is not their selling point.

To prove my point, I spent 6 days with CCS support trying to figure-out the problem which even them couldn't understand. They got me to re-install the compiler twice, do this do that etc. The files I was using were created with the wizard and contained the default lines. Simply adding the "faulty" line caused the error. I then sent them my files and they also got the problem. Then they realized that the line I added made the compiler crash and made it go in an unrecoverable state.

What happened is that I started testing a PIC24HJ-series for the first time two weeks ago. I had never used it and read on-line that pins were re-mappable and that to use a UART, I had to use the #PIN_SELECT directive. WRONG!

I created a base project and hit COMPILE. That worked fine. Then, I added the following:

#PIN_SELECT U1RX=PIN_F2
#PIN_SELECT U1TX=PIN_F3
#use RS232( UART1, baud=9600, bits=8, parity=n)

Then hit compile and that was the end of it. The error was so severe that I hadn't realized that my simple lines of code were making the compiler crash and make it go in an unrecoverable state.

The contents of the .ERR file was as follow:

--------------------------------------------
--- Info 300 "C:\Test.c" Line 11(12,22): More info: *3* I/O error 32
*** Error 44 "C:\Test.c" Line 11(12,22): Internal Error - Contact CCS OUTPUT FILE
1 Errors, 0 Warnings.
Build Failed.
--------------------------------------------

Other variants for the first error lines is

--------------------------------------------
--- Info 300 "C:\Test.h" Line 10(12,22): More info: *3* 'one' is not a valid integer value
--------------------------------------------

The pop-up error box caused by adding the #PIN_SELECT was:

<< Cannot open file "C:\Test.esym". The process cannot access the file because it is being used by another process >>

However, the Test.esym was, on occasions, Test.c and Test.h. So, even the file stated in the pop-up box is inconsistent although nothing was changed in the code between the different times I hit the COMPILE button.

I just thought I'd share this error because it caused a lot a frustration.

[Ttelmah]

I'd say _read the chip's data sheet_.....

Seriously, most 24 chips do have the UART re-mappable, your's doesn't. If you started with the data sheet, you would avoid your first big problem.

The CCS device editor (if you have the IDE), would also tell you. If (for instance) you select the FJ256GB106, and the 'UART', the pins are listed as 'RP' (re-mappable pin). However select the HJ256106, and the pins are listed directly with pin numbers, telling you that the pins are not re-mappable.
So, you were trying to 'map' a fixed pin. Not surprising it didn't work....

Unfortunately the 'error checking' on #pin select is abysmal. Instead of just giving an error that the pin can't be mapped, it crashes the compiler, but the big fault is trying to do things without reading the data sheet first.

Best Wishes

[benoitstjean]

I understand what you're saying... BUT... the fact that such a simple line of code would make the _entire compiler crash_ without ANY significant error message of ANY kind, such as indicating the problematic line of code, didn't even cross my mind that I should have looked at the datasheet because to me, it was a compiler bug, not a code bug.

Perhaps I forgot to provide another important detail that might have changed your answer: once the line was added and made the compiler crash, I had the EXACT SAME error when I hit the SAVE or SAVE ALL button. Imagine... I couldn't even save my files!!.... So think of it... do you REALLY THINK at this point that I thought "Hey, maybe I didn't configure the PIC properly"....? No. The compiler crashed and went into an unrecoverable state when performing a normal basic compiler command - SAVING a file!

If that error would have been a simple error in the bottom of the compiler like EVERY other compiler error, then guaranteed that I would have investigated deeper into the PIC's functionality. As an example, this morning, I created a DMA buffer and I made the size 1024 then compiled and all was fine. Then, I made the buffer 1025 just to see and I got a _compile error_ (as opposed to a compilER error) indicating that there was not enough memory. So right there I knew that it was because of the memory size. Right there, I referred to the specs and the DMA address size for the PIC is 1024 bytes.

So, in the other case, perhaps if I would have had a compile error saying "Cannot assign pin to this PIC type", then the datasheets would have been of use.... but that was not the case.

[Ttelmah]

As I said the error checking is abysmal, _but_ at heart they check for syntax errors, not the user trying to do something impossible. It should flag it and not crash, but if you started from good data, rather than 'rumour' on the internet, the problem wouldn't have appeared.

Best Wishes

[temtronic]

As for the bug crashing the computer....all those who have NEVER had Windows crash their computer raise their hands...hmmm..

I don't know how big a staff CCS has,but considering the huge quantity of PIC variants, I'm impressed as to the compilers overall performance.They not only have to do sales, products,etc. but also customer support.Since '97 CCS has always been helpful in resolving 'issues' for me.
You're using the 24 series device, not the most popular,and I think CCS might look at the more common PICs(16F ,18F) issues first or maybe there's a specialist for each series.
Obviously you should report this problem( and your solution) to them.I know they will act upon it.