CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

CCS 4104 Compiler Bug!
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
monsters_inc



Joined: 18 Jan 2010
Posts: 14

View user's profile Send private message

CCS 4104 Compiler Bug!
PostPosted: Wed Feb 17, 2010 5:25 am     Reply with quote

Hi,
I use CCS 4104 PCWHD compiler with PIC24FJ256GA106.
When I use directive "#type unsigned" compiler replaces in code destination address of one BRA or CALL instruction with 0x20C wich produces PIC restart.
Function with BRA or CALL instruction with wrong destination address depends of code that I add or remove.
If I compile exact same code with v4093 or v 4099 everything is ok.
If I remove directive "#type unsigned" everything is ok with CCS v4104, but I need by default int8, int16 and int32 to be unsigned.
If I compile in debug mode with CCS v4104 everything is ok.

Code:

#include<24FJ256GA106.h>
#type unsigned
#device ADC=10
......
#define write_SPI(data)   spi_write(data); spi_read()
#define read_SPI()         spi_read(0)
......

Compiled code with wrong destination address of BRA instruction - at address 01202h(CCS v4104):
....................          //--- 6 high address bits
....................          write_SPI(Make8(address, 2));
011C2:  MOV     2C60,W5
011C4:  PUSH    248
011C6:  MOV.B   W5L,[W15-#2]
011C8:  POP     248
011CA:  BTSC.B  240.1
011CC:  BRA     11CA
011CE:  BCLR.B  240.6
011D0:  BTSS.B  240.0
011D2:  BRA     11D0
011D4:  MOV.B   248,W0L
011D6:  BCLR.B  240.6
....................          //--- 8 middle address bits
....................          write_SPI(Make8(address, 1));
011D8:  PUSH    2C5E
011DA:  MOV     [--W15],W5
011DC:  LSR     W5,#8,W5
011DE:  PUSH    248
011E0:  MOV.B   W5L,[W15-#2]
011E2:  POP     248
011E4:  BTSC.B  240.1
011E6:  BRA     11E4
011E8:  BCLR.B  240.6
011EA:  BTSS.B  240.0
011EC:  BRA     11EA
011EE:  MOV.B   248,W0L
011F0:  BCLR.B  240.6
....................          //--- 8 low address bits
....................             write_SPI(Make8(address, 0));
011F2:  MOV     2C5E,W5
011F4:  PUSH    248
011F6:  MOV.B   W5L,[W15-#2]
011F8:  POP     248
011FA:  BTSC.B  240.1
011FC:  BRA     11FA
011FE:  BCLR.B  240.6
01200:  BTSS.B  240.0
01202:  BRA     20C                      <---- Wrong destination address - 0x20C
01204:  MOV.B   248,W0L
01206:  BCLR.B  240.6


Compiled code without "#type unsigned" and correct destination address of BRA instruction - at address 01202h (CCS v4104):

....................          //--- 6 high address bits
....................          write_SPI(Make8(address, 2));
011C2:  MOV     2C60,W5
011C4:  PUSH    248
011C6:  MOV.B   W5L,[W15-#2]
011C8:  POP     248
011CA:  BTSC.B  240.1
011CC:  BRA     11CA
011CE:  BCLR.B  240.6
011D0:  BTSS.B  240.0
011D2:  BRA     11D0
011D4:  MOV.B   248,W0L
011D6:  BCLR.B  240.6
....................          //--- 8 middle address bits
....................          write_SPI(Make8(address, 1));
011D8:  PUSH    2C5E
011DA:  MOV     [--W15],W5
011DC:  LSR     W5,#8,W5
011DE:  PUSH    248
011E0:  MOV.B   W5L,[W15-#2]
011E2:  POP     248
011E4:  BTSC.B  240.1
011E6:  BRA     11E4
011E8:  BCLR.B  240.6
011EA:  BTSS.B  240.0
011EC:  BRA     11EA
011EE:  MOV.B   248,W0L
011F0:  BCLR.B  240.6
....................          //--- 8 low address bits
....................          write_SPI(Make8(address, 0));
011F2:  MOV     2C5E,W5
011F4:  PUSH    248
011F6:  MOV.B   W5L,[W15-#2]
011F8:  POP     248
011FA:  BTSC.B  240.1
011FC:  BRA     20C
011FE:  BCLR.B  240.6
01200:  BTSS.B  240.0
01202:  BRA     1200                      <---- Correct destination address
01204:  MOV.B   248,W0L
01206:  BCLR.B  240.6


Has anyone seen something like this?

-------------------------------------------
sorry for my english
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 7:25 am     Reply with quote

So when you declare your var's, use unsigned in their declaration.

Or make a type like MCHP does in all their code. (uppercase stuff like BYTE and WORD)

or uB or uW or uL

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Wayne_



Joined: 10 Oct 2007
Posts: 681

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 8:38 am     Reply with quote

Taken from the help

"Note: All types, except float, by default are unsigned; however, may be preceded by unsigned or signed. "

Notice, all types are unsigned by default anyway!
Ttelmah
Guest







PostPosted: Wed Feb 17, 2010 9:22 am     Reply with quote

This is one of those 'beware of the manual' bits.....

Unsigned, is the default, _unless_ he is running in ANSI mode. The manual has not been updated to reflect this (it is in the 'readme.txt' fo the compiler).
So for every other mode, "#type unsigned", is pointless, but for ANSI mode it is useful. Now 'oddities' with signed values on the latter chips, have been reported here in a number of other threads... :-(
I'd suggest trying in CCS4 mode, and switching the string handling to ANSI if required. Except then for the default integer sizes, this should be close to operating the same.

Best Wishes
Guest








PostPosted: Wed Feb 17, 2010 10:17 am     Reply with quote

Hi, Wayne_, Ttelmah, For PCD compiler(PIC24, dSPIC) by default is signed:
Note: All types, except char, by default are signed; however, may be preceded by unsigned or signed (Except int64 may only be signed). Short and long may have the keyword INT following them with no effect. Also see #TYPE to change the default size.

This is from PCD.CHM.

Best Regards.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 12:58 pm     Reply with quote

CCS tried to make the data types for the PCD compiler be more like conventional C:
Code:

PCD Compiler Reference Manual

C Standard Type  Default Type
short            int8
char             unsigned int8
int              int16
long             int32
long long        int64
float            float32
double           float64

Note: All types, except char, by default are signed.

Compare that to the C18 data types on page 11:
http://ww1.microchip.com/downloads/en/DeviceDoc/C18_User_Guide_51288j.pdf
The PCD compiler still has some differences, such as a 'short' is 8-bits
and a char is unsigned. That's different from ANSI.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 1:59 pm     Reply with quote

The #type preprocessor command has generated unexpected side effects with some previous PCD versions, I stopped
using it since then. The special thing with the present bug is, that it has no reasonable explanation, so it's no clear,
if it generally depends on #type only. In any case, the bug has to be fixed by CCS.

PCD has considerably improved in the last 18 month since I'm using it. In the beginning I found several new bugs
each day. Now it's from time to time.
monsters_inc



Joined: 18 Jan 2010
Posts: 14

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 2:00 pm     Reply with quote

Hi. I added two more files with code to the project and found that the wrong destination addres of BRA, CALL instructions appear with or without directive "#type unsigned".

This is strange!


Last edited by monsters_inc on Wed Feb 17, 2010 2:10 pm; edited 1 time in total
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 2:05 pm     Reply with quote

Quote:
This is strange!
Yes, I feared something like this. You may need to fall back to a previous PCD version, until CCS fixes the bug. I wonder, if there's something special with your application. V4.104 is out since 6 weeks. Someon else should have experienced the problem before.
monsters_inc



Joined: 18 Jan 2010
Posts: 14

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 2:16 pm     Reply with quote

There is nothing special in project. A lot of code for driving three serial ports, SPI and ADC. The strange thing is that always destination address is 0x20C and only on one BRA or CALL instruction!
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Wed Feb 17, 2010 3:03 pm     Reply with quote

There seems to be something really attracting at address 0x20C. Perhaps you find out, what it is.
monsters_inc



Joined: 18 Jan 2010
Posts: 14

View user's profile Send private message

PostPosted: Thu Feb 18, 2010 12:13 am     Reply with quote

Address 20C doesn't exist in listing.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Thu Feb 18, 2010 12:35 am     Reply with quote

Quote:
Address 20C doesn't exist in listing.

The built-in function code starts from 0x200. You have to uncomment the #nolist directive in 24FJ256GA106.h to see it.
monsters_inc



Joined: 18 Jan 2010
Posts: 14

View user's profile Send private message

PostPosted: Thu Feb 18, 2010 1:12 am     Reply with quote

Thanks for info FvM. I'll try.
monsters_inc



Joined: 18 Jan 2010
Posts: 14

View user's profile Send private message

PostPosted: Thu Feb 18, 2010 2:03 am     Reply with quote

Hi, 0x200 is start address of function that pass string char by char to printf function and 0x20C is start address of string.
Code:

.................... #type unsigned
.................... #include "24FJ256GA106my.h"
.................... //////// Standard Header file for the PIC24FJ256GA106 device ////////////////
.................... #device PIC24FJ256GA106
*
00200:  CLR     32
00202:  MOV     #20C,W3
00204:  ADD     W3,W0,W0
00206:  TBLRDL.B[W0],W0L
00208:  CLR.B   1
0020A:  RETURN 
0020C:  DATA    54,69,00
0020E:  DATA    6D,65,00
00210:  DATA    20,6E,00
00212:  DATA    6F,77,00
00214:  DATA    20,69,00
00216:  DATA    73,3A,00
00218:  DATA    20,00,00
....................................................................................
....................................................................................
....................................................................................
.................... int8 DTF_ReadDevID(int8 dbg) 
.................... {
....................    int8 tmp;
.................... 
....................    //--- Wait DTF_Ready
....................    tmp = DTF_WaitReady(1, dbg);
*
00F98:  MOV     #1,W4
00F9A:  MOV     W4,18C4
00F9C:  MOV.B   18C1,W0L
00F9E:  MOV.B   W0L,18C3
00FA0:  CALL    F28
00FA4:  MOV.B   W0L,18C2
....................................................................................
....................................................................................
....................................................................................
....................    tmp = DTF_ReadDevID(dbg);
01154:  MOV.B   18BD,W0L
01156:  MOV.B   W0L,18C1
01158:  CALL    20C                 <--- wrong desrtination address.
0115C:  MOV.B   W0L,18BE
....................................................................................
....................................................................................
....................................................................................
....................    
....................    printf(dbg_putc, "Time now is: ");
01444:  MOV     #0,W1
01446:  MOV     W1,W0
01448:  CALL    200
0144C:  INC     W1,W1
0144E:  MOV     W1,[W15++]
01450:  MOV.B   W0L,18D1
01452:  CALL    E5C
01456:  MOV     [--W15],W1
01458:  MOV     #C,W0
0145A:  CPSGT   W1,W0
0145C:  BRA     1446
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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