 |
 |
| View previous topic :: View next topic |
| Author |
Message |
kda406
Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA
|
| Work around for work around for FP BUG??? |
 Posted: Fri Mar 18, 2005 3:44 pm |
 |
|
Earlier, I posted a work-around to a CCS bug regarding the printf function with floating point numbers:
http://www.ccsinfo.com/forum/viewtopic.php?t=22210
During the implentation of the work-around, I found what I believe to be a separate, nasty bug. In my work-around testing, I was using whole, unsigned 32 bit integers. But in actual implentation, the temperatures are stored in a global int32 array.
When doing the simple math, CCS appears to fail. Here is the code:
| Code: | // Print the raw number from the global signed int32:
fprintf(TERM,"%li\n\r",glTemp[c]);
// Do the bug work around with the array [FAILS]:
w = glTemp[c] / 100;
r = glTemp[c] - w * 100;
fprintf(TERM,"%li.%02lu\n\r",w,(unsigned int32)r);
// Do the bug work around with local signed int32s [works]:
r = glTemp[c];
w = r / 100;
r = r - w * 100;
fprintf(TERM,"%li.%02lu\n\r",w,(unsigned int32)r);
|
Produces this output at room temperature (centigrade here):
| Quote: | 2325
23.23396377
23.25
|
As you can see, all I have done is to substitute the glTemp[c] into r and it works as expected in C. But doing the computations with the array directly, fails. r, w, and glTemp[] are signed int32s, with r and w being locally declared.
I tried using various forms of parenthesis and could not solve the problem.
Am I doing something wrong, or is this another bug???????
-Kyle |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 18, 2005 3:54 pm |
|
|
Can you post the variable declarations and initializations for:
c, w, r, glTemp[]
Need that info in order to make a test program. |
|
|
bluetooth
Joined: 08 Jan 2005
Posts: 74
|
|
| Posted: Fri Mar 18, 2005 4:43 pm |
|
|
Kyle:
I entered the following on a '452 using 3.219...
| Code: |
unsigned int32 gltemp[10];
unsigned int32 r;
unsigned int32 w;
unsigned int x;
// other code in another test program
x = 2;
gltemp[x] = 2325;
// Print the raw number from the global signed int32:
sprintf(outbuf,"%li\n\r",glTemp[x]);
// Do the bug work around with the array [FAILS]:
w = glTemp[x] / 100;
r = glTemp[x] - w * 100;
sprintf(outbuf,"%li.%02lu\n\r",w,(unsigned int32)r);
// Do the bug work around with local signed int32s [works]:
r = glTemp[x];
w = r / 100;
r = r - w * 100;
sprintf(outbuf,"%li.%02lu\n\r",w,(unsigned int32)r);
x = 2; // for setting a breakpoint (ICD2)
|
I ran it and set breakpoints after each sprintf. My "outbuf" contained the correct answers after each sprintf, even the second one (23.25).
It might be worthwhile to just enter a small test program containing this code to see if it works - it's possible your overall program may be interfering with this (corrupted scratches, etc.).
Hope this helps.... |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Mar 18, 2005 5:12 pm |
|
|
Quick thought here. Check your actual chip version against the errata. There is a problem with table reads on some chips, and the 'fix' for this may not be enabled (recently CCS elected to turn off the default fix for the jump bug, since the working chips have been available for at least a year, and this fix might be in the same class). This would affect the use of the arrays for calculations, since these take advantage of the table read functions. If you have a chip with this fault you may need to enable the fix.
Best Wishes |
|
|
bluetooth
Joined: 08 Jan 2005
Posts: 74
|
|
| Posted: Fri Mar 18, 2005 7:31 pm |
|
|
Kyle:
I went back through the old thread - unless I missed it, no one asked you for the chip and version you're running.... this may be helpful.
The test I did was on a Rev 0x06 '452, and I only saw 3 TBLRDs in it in what I believe is not in the math/sprintf stuff (near the beginning). But if it's an old 18 part running a large program that goes across 0x4000 boundaries, that same weird stuff starts happening too.
This is interesting now!  |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Sat Mar 19, 2005 9:45 am |
|
|
I still think it was a major error on Microchips part not to recall and replace these defective 18F452 chips. How the defective chips ever got out there with such an obvious error still shocks me. I know there is always the potential of an errata type issue but this was pretty blatant.
What's next for errata "chips don't work if you apply power to them"? Today mistakes may just not matter anymore...the people responsible for the Microchip testing could well have moved on to doing WMD intellegence quality control...where being completely wrong earns you a big promotion. |
|
|
kda406
Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA
|
|
| Posted: Thu Mar 24, 2005 2:12 pm |
|
|
Hi guys. I just reported this as a bug to CCS. I wanted to try it on the latest version of the compiler first, and found that my maintenance had expired earlier this month.  Funny, they don't e-mail or mail or call or anything to keep that money rolling in. Anyway, got 3.222 and tried both this bug and the other one out again. Both still exist, so both were reported separately. To answer some of the questions in my absense, I am using a PIC18F8720. It is silicon A4, which I believe is the latest revision available. I do not recall any information about a jump bug in this processor.
Here is the complete program I used to report the bug to CCS:
| Code: | #include "18F8720.h"
#use delay(clock=11059200)
#fuses EC_IO,PROTECT,NOOSCSEN,NOBROWNOUT,NOWDT,PUT,CPD,NOSTVREN,NOLVP,NOWRT,NOWRTD,NOWAIT,MCU,NOWRTC,NOWRTB,NOEBTR,NOEBTRB,CPB
///////// IO Port Definitions /////////
#use rs232(baud=115200, xmit=PIN_C6, rcv=PIN_C7, stream=TERM, DISABLE_INTS)
///////////// Global Structures & Enums /////////////
enum tempsensorenum {TEMPAIRIN,TEMPAIROUT, TEMPCOMPSUC, TEMPCOMPPRS, TEMPLOOPIN, TEMPLOOPOUT, TEMPHEATEXCH, TEMPHOTWATER};
const unsigned int8 tempsensorenumnum = TEMPHOTWATER - TEMPAIRIN + 1; // Number of enums
///////////// Global Variables /////////////
signed int16 glTemp[tempsensorenumnum]; // Abridged summary of temperatures by enum category
void main(void) {
signed int32 w,r;
int8 c;
glTemp[TEMPAIRIN] = 2325;
c = TEMPAIRIN;
// Print the raw number from the global signed int32:
fprintf(TERM,"%li\n\r",glTemp[c]);
// Do the bug work around with the array [FAILS]:
w = glTemp[c] / 100;
r = glTemp[c] - w * 100;
fprintf(TERM,"%li.%02lu\n\r",w,(unsigned int32)r);
// Do the bug work around with local signed int32s [works]:
r = glTemp[c];
w = r / 100;
r = r - w * 100;
fprintf(TERM,"%li.%02lu\n\r",w,(unsigned int32)r);
sleep();
} |
I just ran this bug code using 3.222 and it gives me this:
2325
23.393241
23.25
It would be interesting to know if this exact (as possible) code fails for any other processors.
OT: I always try to annotate my code to explain why I inserted work-arounds in case I'm not the guy to revise the code later. I found this bug doing a work-around for another bug. I feel sorry for the next guy to see the annotations for this part of my code to print out a simple number.
-Kyle |
|
|
bluetooth
Joined: 08 Jan 2005
Posts: 74
|
|
| Posted: Thu Mar 24, 2005 3:39 pm |
|
|
Kyle:
Any chance you could try my test program from a few posts back? It ran fine on a '452 - all three answers correct.
Would be interesting to know if it worked. The only real difference is that I used sprintf instead of fprintf.
Let us know... |
|
|
kda406
Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA
|
|
| Posted: Fri Mar 25, 2005 6:54 am |
|
|
I modified my code to be more like the code bluetooth suggested. Here is the code implementation:
| Code: | #include "18F8720.h"
#use delay(clock=11059200)
#fuses EC_IO,PROTECT,NOOSCSEN,NOBROWNOUT,NOWDT,PUT,CPD,NOSTVREN,NOLVP,NOWRT,NOWRTD,NOWAIT,MCU,NOWRTC,NOWRTB,NOEBTR,NOEBTRB,CPB
///////// IO Port Definitions /////////
#use rs232(baud=115200, xmit=PIN_C6, rcv=PIN_C7, stream=TERM, DISABLE_INTS)
///////////// Global Structures & Enums /////////////
enum tempsensorenum {TEMPAIRIN,TEMPAIROUT, TEMPCOMPSUC, TEMPCOMPPRS, TEMPLOOPIN, TEMPLOOPOUT, TEMPHEATEXCH, TEMPHOTWATER};
const unsigned int8 tempsensorenumnum = TEMPHOTWATER - TEMPAIRIN + 1; // Number of enums
///////////// Global Variables /////////////
signed int16 glTemp[tempsensorenumnum]; // Abridged summary of temperatures by enum category
void main(void) {
signed int32 w,r;
int8 c;
char outbuf[2048];
glTemp[TEMPAIRIN] = 2325;
c = TEMPAIRIN;
// Print the raw number from the global signed int32:
sprintf(outbuf,"\n\r%li\n\r",glTemp[c]);
fprintf(TERM,"%s",outbuf);
// Do the bug work around with the array [FAILS]:
w = glTemp[c] / 100;
r = glTemp[c] - w * 100;
sprintf(outbuf,"%li.%02lu\n\r",w,(unsigned int32)r);
fprintf(TERM,"%s",outbuf);
// Do the bug work around with local signed int32s [works]:
r = glTemp[c];
w = r / 100;
r = r - w * 100;
sprintf(outbuf,"%li.%02lu\n\r",w,(unsigned int32)r);
fprintf(TERM,"%s",outbuf);
sleep();
}
|
With the sprintf commands it produces this output:
| Quote: | 2325
23.393241
23.25
|
As you can see, I printed the buffer to the terminal after each sprintf operatoin. Technically, this should still use sprintf to produce the output, I am simply reviewing the character buffer in a way that is easier for me to see.
I noticed that the resultant incorrect answer was the same incorrect answer I was getting on the previous program. One can only conclude it must be a math bug in the PCH compiler when using global int32 arrays. 
-Kyle |
|
|
bluetooth
Joined: 08 Jan 2005
Posts: 74
|
|
| Posted: Fri Mar 25, 2005 7:03 am |
|
|
Kyle:
In your latest code, I see:
| Code: |
///////////// Global Variables /////////////
signed int16 glTemp[tempsensorenumnum];
|
Is this right? I thought you wanted int32's?
By the way, the program I posted works fine on my '452... |
|
|
kda406
Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA
|
|
| Posted: Fri Mar 25, 2005 7:28 am |
|
|
| Quote: | Am I doing something wrong, or is this another bug???????
|
Yeah, this one was the coder, not the compiler. Assign a 32 from a 16 and then subtract the 16 from the 32 and you get a 32 bit answer. I thought the darn glTemp variable was signed int32. This is why I posted the code to the forum before posting the bug report to CCS. Oh well, at least you found my mistake.
This will make my code annotations for the work around for the floating point printing bug much easier to explain. 
THANKS!
-Kyle |
|
|
bluetooth
Joined: 08 Jan 2005
Posts: 74
|
|
| Posted: Fri Mar 25, 2005 7:34 am |
|
|
I was just about to post that when I changed mine to int16's, I got the same "error" - so glad you've got it now.
I agree with the other guys - it would be nice of the float printf were cleaned up - just one less thing to compensate for.
Hopefully that'll get looked at in an upcoming release. If I had my choice, I'd rather they finish the dsPIC compiler before they worry about this one |
|
|
kda406
Joined: 17 Sep 2003
Posts: 97
Location: Atlanta, GA, USA
|
|
| Posted: Fri Mar 25, 2005 7:40 am |
|
|
| There, you and I part ways. My philosophy is "get the current code right before you add any new features." - Kyle |
|
|
bluetooth
Joined: 08 Jan 2005
Posts: 74
|
|
| Posted: Fri Mar 25, 2005 7:59 am |
|
|
| kda406 wrote: | | There, you and I part ways. My philosophy is "get the current code right before you add any new features." - Kyle |
There are levels of "right", and as the system gets more complex, you have to start making decisions that purists don't like. If you don't, you'll go broke looking for that last bug.
I mean, there are still bugs in DOS 6.22 - good thing new product development wasn't held up until they got it "right"!
With a suite like CCS (or any other tool), fixes have to be prioritized. I'm sure it'll get attention in the future. I'm just not that worried about this particular one because I know about it and I know how to fix it. Fortunately, there aren't that many of these things to worry about anymore with this tool.
Anyhoo - I'm glad your problem is solved, and I'm pretty sure there are as many opinions on this as there are members.... maybe a new thread to discuss? Could be interesting!  |
|
|
|
|
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
