|
|
View previous topic :: View next topic |
Author |
Message |
jlvern
Joined: 03 Oct 2003 Posts: 1
|
BUGS in PCWH 3.212 |
Posted: Sat Nov 13, 2004 9:30 am |
|
|
The 4/10/2004 and 13/10/2004, I send two bugs to the CCS Support. I have only the automated answer (4J0468 & 4J2597)
The first bug is a bug in structure assignement :
CCS PCH C Compiler, Version 3.212, 24699 04-oct.-04 14:09
Filename: vhal2.LST
ROM used: 53132 bytes (82%)
Largest free fragment is 11568
RAM used: 2619 (68%) at main() level
2768 (72%) worst case
Stack: 14 worst case (12 in main + 2 for interrupts)
.................... typedef struct{
.................... UBYTE h;
.................... UBYTE mn;
.................... UBYTE s;
.................... ULONG longitude;
.................... ULONG latitude;
.................... UBYTE hdop;
.................... UBYTE nbr_sat;
.................... }NMEA_GGA;
....................
.................... NMEA_GGA const NO_FIX = {
.................... 0xFF,
.................... 0xFF,
.................... 0xFF,
.................... 0xFFFFFFFF,
.................... 0xFFFFFFFF,
.................... 0xFF,
.................... 0xFF
.................... };
.................... NMEA_GGA fix_horaire[NBR_FIX_HORAIRE];
.................... void clear_fix_horaire( void )
.................... {
.................... UBYTE i;
.................... // décale les fix précédants
.................... for( i = 0; i < NBR_FIX_HORAIRE; i++ )
*
42BC: MOVLB A
42BE: CLRF x3B
42C0: MOVF x3B,W i
42C2: SUBLW 08 NBR_FIX_HORAIIRE
42C4: BNC 42EE
.................... fix_horaire[i] = NO_FIX;
42C6: MOVF x3B,W i
42C8: MULLW 0D i*sizeof(NO_FIX)
42CA: MOVF FF3,W
42CC: CLRF 03
42CE: ADDLW 3E &fix_horaire
42D0: MOVWF FE9
42D2: MOVLW 01
42D4: ADDWFC 03,W
42D6: MOVWF FEA FSR0 <- &fix_horaire[i]
42D8: CLRF FE2
42DA: MOVFF 00,FE1 FSR1 <- [00] ?????
42DE: MOVLW 0D
42E0: MOVWF 01
42E2: MOVFF FE6,FEE POSTINC1,POSTINC0<--------- BUG !!!
42E6: DECFSZ 01,F
42E8: BRA 42E2
42EA: INCF x3B,F
42EC: BRA 42C0
.................... }
42EE: MOVLB 0
42F0: RETLW 00
....................
On the other part of the program, the constant struct NO_FIX is correctly assigned :
.................... fix_horaire[0] = NO_FIX ;
6662: MOVLW 01
6664: MOVWF FEA
6666: MOVLW 3E
6668: MOVWF FE9
666A: MOVFF FF2,A3E
666E: BCF FF2.7
6670: MOVLW 0D
6672: MOVWF 01
6674: CLRF FF7
6676: MOVLW 00
6678: CALL 017C
667C: TBLRD*-
667E: TBLRD*+ <- table read OK
6680: MOVFF FF5,FEE
6684: DECFSZ 01,F
6686: BRA 667E
6688: MOVLB A
668A: BTFSC x3E.7
668C: BSF FF2.7
.....
The seconde bug is in define complex constant :
CCS PCH C Compiler, Version 3.212, 24699 13-oct.-04 13:11
#define XTAL 20000000
#ifdef NEW
#define FREQ_TETE 17560
#else
#define FREQ_TETE 4596
#endif
#define CYCLES_PERIODE(x) ((XTAL+(2*FREQ_TETE))/(4*FREQ_TETE))
#define PERIODE_TETE CYCLES_PERIODE(FREQ_TETE)
#if PERIODE_TETE < 512
#define PREDIV_OSC 0
#elif PERIODE_TETE < 1024
#define PREDIV_OSC 1
#elif PERIODE_TETE < 2048
#define PREDIV_OSC 2
#elif PERIODE_TETE < 4096
#define PREDIV_OSC 3
#elif PERIODE_TETE < 8192
#define PREDIV_OSC 4
#elif PERIODE_TETE < 16384
#define PREDIV_OSC 5
#endif
#define TIMING_IT (PERIODE_TETE+(1<<PREDIV_OSC))/(1<<(PREDIV_OSC+1))
238: // Calcule la prochaine interruption
239: TMR0L += (-(TIMING_IT)+3);
00000C E7B MOVLW 0x7b
00000E 24D6 ADDWF 0xfd6, W, ACCESS
// ??????????????????????????????????????? <- Crazy code !!!!!!!!!!!!!!!!!!!!!!!!!!
000010 6E00 MOVWF 0, ACCESS
000012 EFF MOVLW 0xff
000014 6E01 MOVWF 0x1, ACCESS
000016 B0D8 BTFSC 0xfd8, 0, ACCESS
000018 2A01 INCF 0x1, F, ACCESS
00001A EFF MOVLW 0xff
00001C 6E02 MOVWF 0x2, ACCESS
00001E B0D8 BTFSC 0xfd8, 0, ACCESS
000020 2A02 INCF 0x2, F, ACCESS
000022 EFF MOVLW 0xff
000024 6E03 MOVWF 0x3, ACCESS
000026 B0D8 BTFSC 0xfd8, 0, ACCESS
000028 2A03 INCF 0x3, F, ACCESS
00002A C000 MOVFF 0, 0xfd6
When I write
#error (-(TIMING_IT)+3) before :
*** Error 119 "E:\ETUDES\SOFT\ALP.C" Line 240(7,24): (-( ( ((20000000+(2*4596))/(4*4596))+(1<<2))/(1<<(2+1)))+3)
=> the preprocessor constant is OK
if I write
TMROL += 0x7b;
the code is OK
238: // Calcule la prochaine interruption
239: TMR0L += 0x7B;
00000C E7B MOVLW 0x7b
00000E 26D6 ADDWF 0xfd6, F, ACCESS
....
One month later, I would like to have an answer about the two bugs. |
|
|
Trampas
Joined: 04 Sep 2004 Posts: 89 Location: NC
|
|
Posted: Sat Nov 13, 2004 9:48 am |
|
|
I have had the same problem with CCS. The best advice I have to switch to a real compiler, the C18 is not too bad...
Trampas |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sat Nov 13, 2004 4:24 pm |
|
|
It's not a good thing for CCS to be so slow in responding.
Please consider CCS are receiving lots of problem reports and often when looking into the problem it appears to be a user's error. Just check this forum and you will find many 'bug' reports which in the end turn out to be a programming error.
Also, make things easier for the CCS people by sending in a small compilable program that shows the problem. Yes, this will take you some time but it will save CCS a lot of time and in the end we will all benefit from this.
Your examples are not complete, for example:
- The processor type is not mentioned.
- How is 'NEW' defined?
- How is TMR0L declared?
- etc.
Last edited by ckielstra on Sat Nov 13, 2004 4:41 pm; edited 1 time in total |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sat Nov 13, 2004 4:40 pm |
|
|
Your second 'bug' ain't a bug.
Code: | 238: // Calcule la prochaine interruption
239: TMR0L += (-(TIMING_IT)+3);
00000C E7B MOVLW 0x7b
00000E 24D6 ADDWF 0xfd6, W, ACCESS
// ??????????????????????????????????????? <- Crazy code !!!!!!!!!!!!!!!!!!!!!!!!!!
000010 6E00 MOVWF 0, ACCESS
000012 EFF MOVLW 0xff
000014 6E01 MOVWF 0x1, ACCESS
000016 B0D8 BTFSC 0xfd8, 0, ACCESS
000018 2A01 INCF 0x1, F, ACCESS
00001A EFF MOVLW 0xff
00001C 6E02 MOVWF 0x2, ACCESS
00001E B0D8 BTFSC 0xfd8, 0, ACCESS
000020 2A02 INCF 0x2, F, ACCESS
000022 EFF MOVLW 0xff
000024 6E03 MOVWF 0x3, ACCESS
000026 B0D8 BTFSC 0xfd8, 0, ACCESS
000028 2A03 INCF 0x3, F, ACCESS
00002A C000 MOVFF 0, 0xfd6
|
The 14 lines that you call 'Crazy code' are the final part of a 32-bit addition.
The 20MHz clock frequency in your macro is a 32-bit value.... and you are adding the result to the TMR0L (8-bits ???).
Crazy code? No.
Optmized code? No. CCS could improve this.
A bug? No.
Solution: Add a cast operator.
Code: | TMR0L += (int8) (-(TIMING_IT)+3); |
Strange: I can not reproduce your problem in v3.212. I do get optimized code. How did you declare TMR0L? I used optimization level 9, which level did you use? |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sat Nov 13, 2004 7:06 pm |
|
|
Regarding your first bug I took the liberty to write a small test program around your code.
I must admit I don't see why it's not working. Maybe someone else can shine a light on this?
Code: | #include <18F458.h>
#use delay(clock=16000000)
#fuses HS, NOWDT, NOPROTECT, PUT, NOLVP
#define NBR_FIX_HORAIRE 9
#define UBYTE int8
#define ULONG int32
typedef struct{
UBYTE h;
UBYTE mn;
UBYTE s;
ULONG longitude;
ULONG latitude;
UBYTE hdop;
UBYTE nbr_sat;
}NMEA_GGA;
NMEA_GGA const NO_FIX = {
0x01,
0x02,
0x03,
0x04050607,
0x08090a0b,
0x0c,
0x0d
};
NMEA_GGA fix_horaire[NBR_FIX_HORAIRE];
void main()
{
int8 i;
fix_horaire[0] = NO_FIX ; // OK. Copies constant from ROM as expected
for( i = 0; i < NBR_FIX_HORAIRE; i++ )
fix_horaire[i] = NO_FIX; // Error. Copies garbage from RAM. Why?
} |
|
|
|
Charlie U
Joined: 09 Sep 2003 Posts: 183 Location: Somewhere under water in the Great Lakes
|
|
Posted: Sun Nov 14, 2004 9:56 am |
|
|
I worked with this a bit and as ckielstra said, I don't see why it doesn't work either. I even simplified it a bit and used just basic structures, eliminating the typedef declaration. That didn't work either. Then I tried my favorite bug work around, which is to use a temporary variable to hold data and use that variable in the for loop. This worked! Following is the modified main():
Code: |
void main()
{
int8 i;
NMEA_GGA s_temp;
fix_horaire[0] = NO_FIX ; // OK. Copies constant from ROM as expected
s_temp = NO_FIX;
for( i = 0; i < NBR_FIX_HORAIRE; i++ )
fix_horaire[i] = s_temp; // This works.
}
|
I verified this with the MPLAB simulator.
Hope this helps.
By the way, if another poster was correct, CCS has been moving their offices and this may be the reason your bug response may have been delayed. No excuses though. |
|
|
Guest
|
|
Posted: Mon Nov 15, 2004 11:13 am |
|
|
Thanks.
For the constant struct assignement, I use the same workaround.
For the second bug (?), I dont understand why when the define is simpler, the code is correct (LONG or not)...
I use the following declarations
#BYTE STATUS = 0xFD8
#BYTE TMR0L = 0xFD6
#BYTE FSR2L = 0xFD9
...
But you are right, if I cast the constant, the code is correct. |
|
|
Guest
|
|
Posted: Mon Nov 15, 2004 12:23 pm |
|
|
Oups... you are not right, the code is not correct !!!
But if I try some other cast, some cast works !
I think that's a problem with the sign bit...
typedef short int BIT;
typedef unsigned int UBYTE;
typedef signed int SBYTE;
typedef signed long SWORD;
typedef unsigned long UWORD;
typedef unsigned int32 ULONG;
typedef signed int32 SLONG;
typedef union{
UWORD uw;
UBYTE ub[2];
}UWORD_UBYTE;
#define XTAL 20000000
#define PRESCALE 16
#define FREQ_TETE 17560
#define CYCLES_PERIODE(x) ((XTAL+(2*FREQ_TETE))/(4*FREQ_TETE))
#define PERIODE_TETE CYCLES_PERIODE(FREQ_TETE)
#if PERIODE_TETE < 512
#define PREDIV_OSC 0
#elif PERIODE_TETE < 1024
#define PREDIV_OSC 1
#elif PERIODE_TETE < 2048
#define PREDIV_OSC 2
#elif PERIODE_TETE < 4096
#define PREDIV_OSC 3
#elif PERIODE_TETE < 8192
#define PREDIV_OSC 4
#elif PERIODE_TETE < 16384
#define PREDIV_OSC 5
#endif
#define TIMING_IT (PERIODE_TETE+(1<<PREDIV_OSC))/(1<<(PREDIV_OSC+1))
395: // Calcule la prochaine interruption
396: TMR0L += (ULONG)(-(TIMING_IT)+3); // Good, result 0x74
00000C 0E74 MOVLW 0x74
00000E 26D6 ADDWF 0xfd6, F, ACCESS
397: TMR0L = 10; // just for testing to break the CCS constant optimisation
000010 0E0A MOVLW 0xa
000012 6ED6 MOVWF 0xfd6, ACCESS
398: TMR0L += (UWORD)(-(TIMING_IT)+3); // Good, result 0x74
000014 0E74 MOVLW 0x74
000016 26D6 ADDWF 0xfd6, F, ACCESS
399: TMR0L = 10; // just for testing to break the CCS constant optimisation
000018 0E0A MOVLW 0xa
00001A 6ED6 MOVWF 0xfd6, ACCESS
400: TMR0L += (UWORD)((ULONG)(-(TIMING_IT)+3)); // Good, result 0x74
00001C 0E74 MOVLW 0x74
00001E 26D6 ADDWF 0xfd6, F, ACCESS
401: TMR0L = 10; // just for testing to break the CCS constant optimisation
000020 0E0A MOVLW 0xa
000022 6ED6 MOVWF 0xfd6, ACCESS
402: TMR0L += (UBYTE)((UWORD)((ULONG)(-(TIMING_IT)+3))); // Good, result 0x74
000024 0E74 MOVLW 0x74
000026 26D6 ADDWF 0xfd6, F, ACCESS
403: TMR0L = 10; // just for testing to break the CCS constant optimisation
000028 0E0A MOVLW 0xa
00002A 6ED6 MOVWF 0xfd6, ACCESS
404: TMR0L += -TIMING_IT; // False,big code
00002C 0E71 MOVLW 0x71
00002E 24D6 ADDWF 0xfd6, W, ACCESS
000030 6E00 MOVWF 0, ACCESS
000032 0EFF MOVLW 0xff
000034 6E01 MOVWF 0x1, ACCESS
000036 B0D8 BTFSC 0xfd8, 0, ACCESS
000038 2A01 INCF 0x1, F, ACCESS
00003A 0EFF MOVLW 0xff
00003C 6E02 MOVWF 0x2, ACCESS
00003E B0D8 BTFSC 0xfd8, 0, ACCESS
000040 2A02 INCF 0x2, F, ACCESS
000042 0EFF MOVLW 0xff
000044 6E03 MOVWF 0x3, ACCESS
000046 B0D8 BTFSC 0xfd8, 0, ACCESS
000048 2A03 INCF 0x3, F, ACCESS
00004A C000 MOVFF 0, 0xfd6
405: TMR0L = 10; // just for testing to break the CCS constant optimisation
00004E 0E0A MOVLW 0xa
000050 6ED6 MOVWF 0xfd6, ACCESS
406: TMR0L += (UBYTE)(-(TIMING_IT)+3); // False, result 0xF4
000052 0EF4 MOVLW 0xf4
000054 26D6 ADDWF 0xfd6, F, ACCESS
407: TMR0L = 10; // just for testing to break the CCS constant optimisation
000056 0E0A MOVLW 0xa
000058 6ED6 MOVWF 0xfd6, ACCESS
408: TMR0L += (UBYTE)((ULONG)(-(TIMING_IT)+3)); // False, result 0xF4
00005A 0EF4 MOVLW 0xf4
00005C 26D6 ADDWF 0xfd6, F, ACCESS |
|
|
|
|
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
|