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

Arbitrary PCD changes

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

Arbitrary PCD changes
PostPosted: Wed Mar 31, 2010 6:09 am     Reply with quote

I just noticed, that in PCD V4.106 previously existing interrupt definitions have been erroneously removed from the
device file, in this case INT_DMAERR for all PIC24FJ chips. It's rather annoying, that I apparently have to expect
compilation failure of existing applications with each new PCD version.

I would expect, that these kind of artefacts are avoided by basic quality control.
dezso



Joined: 04 Mar 2010
Posts: 102

View user's profile Send private message

PostPosted: Wed Mar 31, 2010 7:08 am     Reply with quote

This is reason #27 why I hesitate to spend $600 on this.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Thu Apr 01, 2010 9:24 am     Reply with quote

CCS support clarified, that the said INT_DMAERR isn't available in PIC24FJ hardware. Unfortunately,
it had been included in the PCD valid interrupts documentation up to V4.105.

So in this case, CCS didn't introduce a new bug, but intended to remove an existing specification error (that
did no harm yet). As usual, it's undocumented in the "recent changes" list.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sun Jun 27, 2010 4:27 am     Reply with quote

I was just aware, that the code for spi_read() built in function in PCD, that has been working for two years has been
replaced by erroneous code in V4.109. It's causing a watchdog reset in my application.

Code:
spi_read(0xAB);

CCS PCD C Compiler, Version 4.109 CAUSES WDT RESET AT A8BE/A8C0
 
0A8B0:  MOV.B   #AB,W0L
0A8B2:  MOV.B   W0L,248
0A8B4:  BCLR.B  240.6   ; SPIROV
0A8B6:  BTSC.B  240.1   ; SPIxTBF transmission started ?
0A8B8:  BRA     A8B6 ; No
0A8BA:  BTSC.B  240.0   ; SPIxRBF
0A8BC:  MOV.B   248,W0L ; Get received data TOO EARLY!
0A8BE:  BTSS.B  240.0   ; SPIxRBF Receive complete?  MUST BE DONE BEFORE READING SPIxBUF!
0A8C0:  BRA     A8BE ; LOOPS FOREVER IF SPIxRXB HAS BEEN READ BEFORE
 
CCS PCD C Compiler, Version 4.107 WORKING CORRECTLY
 
06FCC:  MOV.B   #AB,W0L
06FCE:  MOV.B   W0L,248 ; Put transmit data and start transmission
06FD0:  BTSS.B  240.0   ; SPIxRBF Receive complete?
06FD2:  BRA     6FD0
06FD4:  MOV.B   248,W0L ; Get received data
06FD6:  BCLR.B  240.6   ; SPIROV Clear possible overflow from previous receives


I should add for explanation, that a combination of spi_read() and spi_write() has never been working correctly with
PCD because of an uncorrect handling of status bits, as reported before at CCS Forum. Using spi_read() both for
read and write worked perfectly, however. Possibly CCS tried to change this situation now, but the attempt backfired
completely. As in most cases, there isn't even a hint about changes to SPI functions in the version log.

I have to fall back to known operational V4.107 for the time being.
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Sun Jun 27, 2010 6:33 am     Reply with quote

It does need to be said that 4.099 is the last version CCS considers a stable
release (shown on the upper right side of the download page). All releases
after that are considered beta. I keep two copies installed. One is the
stable release (version 4.099) I use for production and the other is the latest
release (4.109 in this case) for testing.

I have been hoping for years they would change the wording on their web
site to reflect this....maybe one day!
_________________
Google and Forum Search are some of your best tools!!!!
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sun Jun 27, 2010 9:20 am     Reply with quote

I didn't yet notice a remark on the update page about "stable" or beta versions. In my opinion, V4.099 has been kept because many changes have been officially introduced starting with V4.100. Does this mean, that V4.099 is more stable than later versions? I fear, it isn't. A large number of bugs has been continuously fixed with new releases, some are still continued, a few have been newly introduced, as in the present case.

But in any case, you should keep a compiler version, that has been used for a production release.
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Sun Jun 27, 2010 9:14 pm     Reply with quote

Historically, since back in version 3, the version on the right of the Download
page has been the latest "full and stable" release and the version on the left
is considered beta. I have been a CCS user since 2003 and I believe that is
still the case. Like I said earlier, it would be nice if CCS was up front about
this.

PCM and TTelmah, please correct me if I am wrong, is this the way you understand it?
_________________
Google and Forum Search are some of your best tools!!!!
Ttelmah



Joined: 11 Mar 2010
Posts: 19327

View user's profile Send private message

PostPosted: Mon Jun 28, 2010 2:04 am     Reply with quote

Basically yes.
Except when they are doing major updates, when the 'new' version is more like an 'alpha'....

The thing that makes it really hard to know what is likely to give problems, is the poor documentation of the changes. They basically report 'one thing' changed with a release, when in reallity most have several dozen parts tweaked.

My own approach is always to document in the source code, what compiler was used with it, and when I archive sources, archive the compiler used with it. When I try a new compiler, I keep the old, till I have verified that the code I am working on, works with the new version. Once this is 'true', update the note in the source, to say this. The note is always 'cumulative'. So (for example):
Code:

//4.078 Original version
//4.084 Had to change calls to USB initialisation - see notes
//4.099 Worked well
//4.104 OK initially, but introduced new problems. USB code much smaller
//4.099 with 4.104 USB Current version


This is for one project I am currently using. Here I found that 4.104, added some new problems, but that the new USB includes worked better. So this is currently being compiled with 4.099, but using the 4.104 USB include files.
Because I keep the 'track back', I can step backwards if problems appear later. This happened here with me going back to 4.099, but trying the 4.104 includes with this...

Best Wishes
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sun Aug 15, 2010 11:20 am     Reply with quote

spi_read() is O.K. again with PCD V4.110, also spi_write() seems to work finally as expected.

But why this #FUSE name has been changed?
Code:
#IF  getenv("VERSION")>=4.110
   #FUSES WDT128   //Watch Dog Timer PreScalar 1:128
#ELSE
   #FUSES WPRES128   //Watch Dog Timer PreScalar 1:128
#ENDIF
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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