| View previous topic :: View next topic |
| Author |
Message |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
| Under construction - undocumented PCD changes in V4.094- |
 Posted: Tue Sep 01, 2009 7:50 am |
 |
|
Hello,
I was just aware of the fact, that global interrupt enable doesn't work any more in my project when compiled with recent PCD versions.
| Code: | | enable_interrupts(INTR_GLOBAL); |
It turned out, that since PCD V4.094 NSTDIS (Nesting disable) is set in the startup code
| Code: | .................... void main()
.................... {
*
05FD0: MOV #4444,W0
05FD2: MOV W0,A4
05FD4: MOV #4444,W0
05FD6: MOV W0,A6
05FD8: MOV #4444,W0
05FDA: MOV W0,B2
05FDC: BSET.B 81.7 //NSTDIS = 1 |
until V4.093, NSTDIS has been reset instead.
As a sideeffect, the interrupt priority bits in the status register get read only, so below built-in functions are ignored
| Quote: | .................... enable_interrupts(INTR_GLOBAL);
02992: CLR 42
.................... disable_interrupts(INTR_GLOBAL);
0604C: MOV #E0,W4
0604E: MOV W4,42 |
Also the meaning of
| Code: | enable_interrupts(INTR_NESTING);
disable_interrupts(INTR_NESTING); |
has been reversed since V4.094. Obviously the previous definition has been wrong.
It should be mentioned, that NSTDIS=0 doesn't enable interrupt nesting unless different interrupt priorities are set in IPCx registers. By default, all priorities are equal to 4, so no nesting can't occur. The only immediate effect of NSTDIS is, that it disables global interrupt control when set.
By the way, how do you think about the CCS practice of silent bug removal (either real or apparent ones)?
Best regards,
Frank |
|
 |
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Sep 01, 2009 4:02 pm |
|
|
Of the various versions I can use -
4.085 seems to be the most stable for 12f --thru 18f parts
Because I reiterate every setting I use,
and take few defaults for granted - I don't suffer to much when stuff gets wacked out in an update.
U C - I don't expect perfect transparency from the compiler maker on WHAT exactly was fixed ( tho it would be nice).
Mainly because I doubt I could get it. 
What would be FAR more helpful as a guide to stability would be the
DATE each update release was generated.
I think 4.085 was a minor fix to a more major tweak in 4.084.
But since then - there is a crazy jig being danced of Fix-break-fix-break
going on and I don't think I am ready to trust the .09x stuff at all.
Just to be safe - I am hanging back from installing new releases - so long as I have no issues with the one I'm using - In the WAY that I use it.
In short - I don't update just because I can. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Sep 01, 2009 4:28 pm |
|
|
| Quote: |
By the way, how do you think about the CCS practice of silent bug
removal (either real or apparent ones)?
|
CCS has been asked years ago to do a better versions page than this
http://www.ccsinfo.com/devices.php?page=versioninfo
(one that shows all changes), but they just don't want to do it: |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Wed Sep 09, 2009 11:19 pm |
|
|
Methinks they tend to be overwhelmed.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Dec 07, 2010 4:26 pm |
|
|
CCS finally offered a solution for the NSTDIS issue, introduced somewhere between V4.107 and V4110. There are two options available:
- In the standard variant, nesting is disabled as since V4.094. To make the enable/disable of global interrupts work again, NSTDIS is reset and set around each access to the interrupt level field in status register. As a problem, code that directly writes to the status register will possibly fail.
- Alternatively, a new directive #device NESTED_INTERRUPTS leaves nesting enabled as before V4.094. The generated code is more compact, and no interrupt nesting actually takes place, unless different priorities are assigned to interrupts. The directive is documented in readme.txt. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Tue Dec 07, 2010 4:54 pm |
|
|
Thanks for the update...
Some days I think I'll move off the PIC18's to go to PIC24's...
But it doesn't seem to happen. So many useful things to do on PIC18 still. :D
Heheh...
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
arocholl
Joined: 14 Dec 2008
Posts: 21
|
|
| Posted: Mon Dec 20, 2010 8:32 am |
|
|
The only practical way to trust a new CCS compiler version is to actually compare assembler output. This is working well for me and tells me whether I should upgrade for a given code or not.
Basically do this: Say you are working on 4.084 and have a working code in .C. First step is to keep the disassembler .lst renamed to something like _084.lst. Then recompile it in the new version, say 4.110, and compare the new lst with the old one, using WinMerge or similar tool.
Only after you know what the new version changed you can safely assume you can upgrade. Of course moving to a new version for a completely new code is a different story, you need to tweak all the issues as you find them. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
