 |
 |
| View previous topic :: View next topic |
| Author |
Message |
selsen
Joined: 16 Mar 2007
Posts: 9
|
| I am sick of errors with PCD after version 4.099 |
 Posted: Tue Mar 09, 2010 12:57 am |
 |
|
I compiled same project with 4.099 and 4.105 here is the difference in lst files:
4.099:
| Code: |
.................... CHK=seqread_ext_eeprom(0,STORAGE,EEPEND);
*
147AC: CLR 17A6
147AE: CLR 17A8
147B0: MOV #800,W4
147B2: MOV W4,17AA
147B4: MOV #325,W4
147B6: MOV W4,17AC
[b]147B8: CALL 14698[/b]
147BC: MOV W0,17A4
///////////////////////////////////////////////////////////////////////////////////
.................... int16 seqread_ext_eeprom(int32 address, int8* p, int16 bytes)
.................... {
*
1465E: MOV W5,[W15++]
14660: MOV W6,[W15++]
.................... int16 i,CHK;
....................
.................... CHK=0;
14662: CLR 17B0
....................
.................... i2c_start();
.................... if(CHK!=read_e2prom16(CHKSUM1))
|
4.105:
| Code: |
.................... CHK=seqread_ext_eeprom(0,STORAGE,EEPEND);
*
14772: CLR 17A6
14774: CLR 17A8
14776: MOV #800,W4
14778: MOV W4,17AA
1477A: MOV #325,W4
1477C: MOV W4,17AC
[b]1477E: CALL 1300E[/b]
14782: MOV W0,17A4
///////////////////////////////////////////////////////////////////////////////////
.................... int16 seqread_ext_eeprom(int32 address, int8* p, int16 bytes)
.................... {
*
1465E: MOV W5,[W15++]
14660: MOV W6,[W15++]
.................... int16 i,CHK;
....................
.................... CHK=0;
14662: CLR 17B0
....................
.................... i2c_start();
|
The device is PIC24FJ256GB108.
This code has bootloader #0x400-#13FF |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Mar 09, 2010 12:31 pm |
|
|
I guess, the bug has been already introduced between V4.100 and V4.104. There have been more reports of erratic
function addressing with recent compiler versions. By chance, I didn't yet experience the problem. There are however newly
introduced bugs respectively unexpected and unwanted (as well as unsaid!) changes to PCD in V4.105. I just had to
complain about at CCS.
| Quote: | my existing applications for PIC24FJ128GA106 don't compile
any more, because all WPFPx and NOWPFx fuses have been
removed from the device file. There's no respective info in "recent
changes".
I have to fall back to the V4.104 device file for the time being,
because I'm not motivated to reproduce all fuse definitions in the
device editor tool. I guess, you have been finally aware of
inconsistencies with the previous memory protection fuse
definition, that have been reported since long, but the fuses have
been working in my application though. |
|
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Mar 09, 2010 4:04 pm |
|
|
CCS has answered my support request considerably fast (after 2 1/2 hours). It turns out, that a new syntax
for PIC24 fuses has been introduced silently. It allows to set a configuration word bit field in a single expression.
To protect code pages 0 to 3, the new setting is
| Code: | | #FUSES WPDIS, WPEND_HIGH, NOWPFP=3 |
From V4.099 to V4.104, it was
| Code: | | #FUSES WPDIS, WPEND_HIGH, WPFP0,WPFP1, NOWPFP=2,NOWPFP3,NOWPFP4,NOWPFP5,NOWPFP6,NOWPFP7,NOWPFP8 |
Up to V4.098, the necessary setting has been
| Code: | | #FUSES WPDIS, WPEND_HIGH, WPFP3 |
Because the new syntax removes the inconsistencies of previous versions, it's hopefully stable now.
Thanks for the fast response, the change should have been mentioned in the recent changes and readme.txt, however.
P.S.: The version dependant fuses settings can be achieved best with
| Code: | #IF getenv("VERSION")>=4.105
#ELIF getenv("VERSION")>=4.099
#ELSE
#ENDIF |
|
|
|
LostInSpace
Joined: 09 Mar 2010
Posts: 13
|
|
| Posted: Tue Mar 09, 2010 4:58 pm |
|
|
| Well - they do introduce errors, but as has been my experience also they (CCS) do respond to serious errors pretty fast. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Mar 09, 2010 5:23 pm |
|
|
| Quote: | | they (CCS) do respond to serious errors pretty fast |
I don't want to contradict, it's basically good.
Errors regarded not so serious apparently may have to wait longer. I'm waiting for some PCD bug fixes more
than a year. The support status is staying at "A priority has not yet been determined for this issue". |
|
|
selsen
Joined: 16 Mar 2007
Posts: 9
|
|
| Posted: Wed Mar 10, 2010 12:18 am |
|
|
| They have to work on the PCD compiler there are so many empty spots. First I need to use the compiler safely. This is not a game, we are making money with this. Otherwise I will use other compiler or other MCU maybe. |
|
|
jbmiller
Joined: 07 Oct 2006
Posts: 73
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 10, 2010 6:47 am |
|
|
OK, so the compiler has a few issues, but there are other options.
You can not upgrade from a known good version.
You can migrate to another chip, if it's a hardware issue, either PIC or other family.
And of course you could go back to cutting pure assembler code.
As one who grew up on PDP-8's with papertape readers, I can appreciate
the time,effort and money that CCS has into every product they sell and
support.You get a great bang for the buck from where I sit. |
|
|
|
|
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
