![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
The bad habit of silent compiler changes |
Posted: Sat Oct 24, 2009 9:55 am |
|
|
A year ago, I reported some irregularities in PCD's understanding of flash protection bit, partly cause by
an inconsistent Microchip documentation.
http://www.ccsinfo.com/forum/viewtopic.php?t=36155
Now I realized, that CCS has changed the PCD behaviour in this regard, unfortunately without telling a word,
neither in the version log nor in readme.txt. I didn't become aware the change immediately, because I set
the fuses only when flashing the bootloader, the most recent version has been compiled with V4.098.
Luckily, I got it before giving the update to the customer.
The below fuses have been working up to V4.098 to protect Page 0..3 (area 0..0xFFE) and Configuration bits
Code: | #FUSES WPEND_HIGH //Segment protection low (!!)
#FUSES WPDIS //Segment protection enabled(!!)
#FUSES WPCFG //Last page & Configuration protected
#FUSES WPFP3 //Code page 0..3 protected |
This has been the resulting configuration word (from PCD *.lst file)
Quote: | Word 3L: 0003 WPEND_HIGH WPCFG WPDIS WPFP3 | Using the same fuse setting with V4.099 gives a completely different configuration word
Quote: | Word 3L: 00FF WPEND_HIGH WPCFG WPDIS WPFP3 WPFP4 WPFP5 WPFP6 WPFP0 WPFP1 WPFP2 WPFP7 NOWPFP8 |
The V4.099 configuration simply protects the full flash area, so the bootloader and EEPROM emulation
aren't working anymore.
It turned out, that CCS has applied two different changes:
- changed the interpretation of WPFPx fuses to binary coded, as they are understood by Microchip
- introduced a default state with WPFP0..WPFP7 set and WPFP8 cleared (why!).
To re-establish the intended configuration, I had to insert the below version depended compilation
Code: | #IF getenv("VERSION")>=4.099
#FUSES WPFP0,WPFP1
#FUSES NOWPFP2,NOWPFP3,NOWPFP4,NOWPFP5,NOWPFP6,NOWPFP7,NOWPFP8
#ELSE
#FUSES WPFP3 //Code page 0..3 protected
#ENDIF |
The newly introduced default setting seems to indicate, that CCS still doesn't understand the real operation
of the PIC24 memory protection fuses - or applied a change without checking the result. But whatever has
been intended here, it's absolutely inacceptable to do it silently.
It's clear to me, that you can't completely avoid unexpected side-effects when updating a software.
But this issue is different. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Oct 24, 2009 11:38 pm |
|
|
This is related to the previous thread. What's your suggestion for CCS ?
I think they could do one of several things:
1. Release vs. 4.100 in its current state, with whatever new features are
ready. If some new features aren't yet ready, release them at a later
date in vs. 4.010 or 4.020 (etc). But start doing bug fixes with normal
version updates again.
2. Declare that vs. "4.100" is behind schedule. Its release will be
postponed, and will be done as vs. "4.200" at some future date.
(This announcement might be made with some embarrassment).
Start doing normal bug fixes again with vs. 4.100, 4.101, etc.
3. Continue delaying "vs. 4.100" for weeks or months, while doing hidden
bug fixes.
They are currently doing #3. I favor them doing #1, or even #2.
But stop the hidden updates. |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun Oct 25, 2009 1:59 am |
|
|
Although the above issue is somewhat special, it's a good idea to discuss it in conjunction with V4.099/V4.100 problem.
Regarding the present situation, missing or blocked bug fixes are the more serious problem, I fear. The said hidden subversion problem http://www.ccsinfo.com/forum/viewtopic.php?t=40492 is only the "tip of the iceberg".
I don't know, which changes are actually involved with V4.100. From the advertising, I would expect some more basic changes than just a simple update. Probably, you shouldn't port an active project to V4.100 before assuring, that there aren't any unexpected side effects.
From a marketing view, it's unacceptable to cancel the V4.100 milestone. So releasing clearly identifiable subversions for the time being is the best solution in my opinion.
Coming back to the addressed PCD fuses problem. The basic problem is, that PCD is in part still a construction site. There's a number of unfixed reported bugs and probably additional bugs (e.g. with hardware related built-in functions), that didn't yet reveal. You can be sure, that customers don't report each bug to CCS, if they already found a workaround. That's simply a matter of economic developing.
Personally, I would prefer a detailed revision history, that lists all changes of the compiler.
At least, a clear warning must be issued for functional changes, that possibly affect existing applications, as in the present case.
As an example of a detailed revision history, see the below BECK IPC RTOS release notes:
http://www.beck-ipc.com/de/download/load.asp?f=/releasenotes/SC13V0126_ReleaseNotes.pdf |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Sun Oct 25, 2009 3:10 am |
|
|
This is not specific though to the work towards V4.100. CCS have done this from day one. A search through old threads will find the many moans about it. You can reckon that the 'documented' changes to a compiler version, probably represent less than 10% of what has actually been done. This is why in the past there were three bits of advice commonly posted:
1) Unless a new version fixes a specific problem that you _need_ the fix for, treat all new versions as beta's till you have had a good chance to try them.
2) When loading a new version, keep the last one as well, till you are sure what the effects of the new version are.
3) When working on a project, store the compiler version used, with the project's own archive, so that you have it available if going 'back' at a future data.
It is one of CCS's annoying habits, and one that may people have moaned about... :(
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Sun Oct 25, 2009 1:11 pm |
|
|
One of the "biggies" that has been promised is the the Microchip TCP/IP stack would directly compile in version 4.100. That kind of compatibility is a huge change and I would expect that's part of the holdup. _________________ Google and Forum Search are some of your best tools!!!! |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Oct 25, 2009 1:14 pm |
|
|
What bothers me is that with that level of a change, we might have to
wait until vs. 4.165 to have a fully working compiler. I would rather that
they didn't do that. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|