 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mikeyghuuu
Joined: 15 Jun 2007
Posts: 3
|
| CCS C Compiler gets Internal Error when using in vista |
 Posted: Fri Jun 15, 2007 9:04 am |
 |
|
my CCS C Compiler version is 3.173..when i using this compiler in windows vista, and compiler the project,it always shows an internal error.
does anybody have solution to this problem. thank you very much![/b] |
|
 |
fastlink30
Joined: 14 May 2007
Posts: 33
|
|
| Posted: Fri Jun 15, 2007 11:14 am |
|
|
i think is better if you update the compiler   |
|
|
Guest
|
| baudrate can't use 115200bps in version 4 |
| Posted: Sat Jun 16, 2007 3:13 am |
|
|
i updated the CCS C compiler to version 4, and copy "pcb.crg","pch.crg","pcm.crg", to the installtion direction. but when i compile my project, it shows can't use 115200bps, baudrate out of range.
can anybody help to solve this problem?? thank you very much  |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Jun 16, 2007 3:51 am |
|
|
What was your older version?.
What is your clock rate on the chip?.
The #use command, was 'tightened up', with regards to what baud error it would accept, quite a few versions ago (mid 3.2xx version somewhere), and will now complain, and not accept a baud rate error over about 3% (quite a sensible limit for reliability). I'd suspect you are updating from an older version that had wider limits, and it is now complaining that this is not really 'useable'...
Best Wishes |
|
|
Guest
|
|
| Posted: Sat Jun 16, 2007 6:28 am |
|
|
i use 25MHZ clock. The problem is when i use version 3.1 compiler, i can use 115200 baudrate in the #use232...but after i update to version 4, and replace the three files with newer one, it has the out of baudrate range error.....  |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Jun 16, 2007 7:12 am |
|
|
| Quote: | | when i use version 3.1 compiler |
CCS compiler versions always have 3 digits after the decimal dot. Examples are 3.187, 3.249, 4.041. The version number can be found at several places, easiest is to look at the top of the list file (*.lst). You already posted this as being 3.173.
The error message you get is not so much a compiler error as a warning that you are trying to set a configuration that is not going to work reliable.
The baudrate generator in the PIC prcessor can only divide the 25MHz source clock by a number that is a multiple of 2, for example 128, 256, 512, etc. This will result in a baudrate that is not exactly 115k2. For RS232 to work reliable the baudrate error shouldn't be larger than about 3%. In order to prevent you from setting an invalid configuration the CCS compiler added a check for this around version 3.180.
There are several ways two work around the error message:
1) Choose another baudrate that is within the 3% error tolerance, for example 57k6.
2) Choose another clock frequency, for example 22.1184MHz will fit the 115k2 exactly. |
|
|
steve h
Guest
|
|
| Posted: Sat Jun 16, 2007 8:01 am |
|
|
Another option is to tell the compiler that you are using a 25 MHz clock, set a baud rate that works - then after the compiler sets the RS232 baud rate bits you go and poke in the values from your old compiler that you know works.
That way you get back to the way you were.
It is annoying to have to work around something that used to work very well, but at least there is a simple work around.
Just an idea - HTH
Steve H. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Jun 16, 2007 9:00 am |
|
|
| steve h wrote: | Another option is to tell the compiler that you are using a 25 MHz clock, set a baud rate that works - then after the compiler sets the RS232 baud rate bits you go and poke in the values from your old compiler that you know works.
That way you get back to the way you were.
It is annoying to have to work around something that used to work very well, but at least there is a simple work around. |
With the 25MHz crystal the compiler CAN NOT configure for a reliable 115k2 baudrate, that is what the error message says. With the older PIC models it will be either:
25MHz / (16 * 13) = 120,192 (+4.3%)
or
25MHz / (16 * 14) = 111,607 (-3,1%)
If you do accept that the baudrate will have a large error than simply tell the compiler to generate a baudrate of anything between 111k aan 115k and it won't complain anymore. Note that even 115k will fit while 115k2 exceeds the compiler's 3% error margin. |
|
|
Steve H
Guest
|
|
| Posted: Sat Jun 16, 2007 10:09 pm |
|
|
I guess it wasn't clear what I suggested - I meant what you describe - set a normal baud rate that makes the compiler happy. Then since the chap had working code in the past - manually POKE in the same values for PIC registers TXSTA and SPBRG to make them they way the last compiler set them in his application. This makes sure that the application run the same baud rate (whatever it is) as it did in the past - all since his earlier code did work and you wouldn't want to be different now.
You can always POKE the registers in the PIC yourself and the compiler won't know.
HTH - Steve H. |
|
|
mikeyghuuu
Joined: 15 Jun 2007
Posts: 3
|
|
| Posted: Sun Jun 17, 2007 12:30 am |
|
|
maybe i need to repeat my problem: exact same project, when i compiled it using version 3.173 compiler in windows XP, it worked fine. when i compiled in windows vista, it got "Internal Error ". so then i update the compiler to version 4, and replace these three files ""pcb.crg","pch.crg","pcm.crg" with newer ones, it shows can't use 11520 0bps baudrate........exact same project  |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Jun 17, 2007 2:48 am |
|
|
| mikeyghuuu wrote: | | maybe i need to repeat my problem: exact same project, when i compiled it using version 3.173 compiler in windows XP, it worked fine. when i compiled in windows vista, it got "Internal Error ". so then i update the compiler to version 4, and replace these three files ""pcb.crg","pch.crg","pcm.crg" with newer ones, it shows can't use 11520 0bps baudrate........exact same project |
You are missing the point.
115200, with a 20MHz clock, is a dangerous combination to use. On RS232, using 8bits, no parity, the total timing error between the ends of a RS232 link, must not exceed 5%. Now no system is perfect, and you therefore must assume that there will be timing errors at both ends. In general, it is recommended that timing errors don't exceed 2.4% at each end, which gives a 'worst case', total of 5%, if the two ends fail in opposite directions. In early CCS compilers, they did not check for qite severe errors here, allowingf a very wide latitude to this, and you could compile code with errors out to about 5%. This led to a lot of unreliable comms. CCS therefore elected to add a check that the error was not too large for reliability, and give your error, if the timings are out by more than about 3%.
Now if your systems have worked, you have been lucky. If you are talking to a PC for example, com frequency errors at the PC end of a couple of percent, are 'common', and the CCS test is essential for reliable communications.
You can avoid the error check in the compiler (and don't have to fiddle around poking any registers), by selecting the nearest _possible_ rate for your clock. Hence if you use 111,607 in your USE RS232 statement, the compiler will happily put the closest possible value into the registers (-3.1%). This is what was happening with the older compiler. However in all seriousness, this _is_ a potential error with your system. For example, on my own boards performing serial I/O, where high reliability at fast rates is needed, I generally use a crystal, that is a multiple of the required rate. 23.040MHz, or 27.648MHz would be classic choices. Historically, many years ago (pre CCS), I remember asking Microchip, if their then fastest processor (specified at 4MHz), would run on a 4.096MHz clock, to avoid this problem (they said it would).
You have been running with a hardware error, which the compiler has now 'picked up' on. If you are happy to keep running with this error, then just use the data rate that the sytem can produce. However really it would be better to solve the problem...
Best Wishes |
|
|
mikeyghuuu
Joined: 15 Jun 2007
Posts: 3
|
|
| Posted: Mon Jun 18, 2007 2:11 am |
|
|
this is part of my headfile:
#include <18F8720.h>
#device ICD=TRUE
#fuses HS,PROTECT , NOWDT,BROWNOUT,BORV25, STVREN, NOLVP, MCU
#use delay(clock=25000000)
//#priority rda,timer1
#use rs232 (baud=115200, xmit=PIN_C6, rcv=PIN_C7,ERRORS,BITS=8,PARITY=N,STREAM=COM1) |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Jun 18, 2007 11:44 am |
|
|
Sigh... 
Which part did you not understand?
In simple words:
Software ok. Hardware bad.
You are lucky the hardware is working.
The newer compiler versions do give you a warning for the hardware error.
Fix: choose one of the three given solutions. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
