|
Jerry is absolutely correct, you are free to use as much or as little of the
SDK as you want. And yes, you still have this ability with CW 5.02 and SDK 2.5, we have been using them since August 22 and have had no problems in this regard. Basically, the SDK is structured so that it is very simple (in the file "appconfig.h") to choose which SDK features you want to include in your software. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com -----Original Message----- From: Johnson, Jerry [mailto:] Sent: Wednesday, October 09, 2002 9:55 AM To: 'Corey, Rick'; ' Subject: RE: [motoroladsp] RE: Interrupt/context problem? I only feel as though I should comment on one point in your message, which is the avoidance of the SDK to allow you to "not" use the MSCAN premium code, rather do your own thing with regard to CAN programming. As far as I know, and I have been doing it with SDK 2.4 and Codewarrior 4.1, is that you can easily not include MSCAN support, write your own CAN code, and still use all of the rest of the SDK. Since I am starting the switch to CW 5.02 with SDK2.5, I am expecting to still do my own thing regarding CAN bus operation. I hope my expectations are still valid, and my existing code will still work??? Jerry. -----Original Message----- From: Corey, Rick [mailto:] Sent: Tuesday, October 08, 2002 5:26 PM To: ' Subject: RE: [motoroladsp] RE: Interrupt/context problem? warning: long post If you have IRQ madness when using "#pragma interrupt" without the SDK, go to "mixed mode" or "disassemble" and look at your ISR postambles - I have often seen an RTS instead of an RTI at the end of my ISRs. Yes, push the status register and never pop it. I am _not_ using the SDK, just plain vanilla 56803 EABI stationary. I have to avoid the MSCAN SDK and just use the Metrowerks compiler "#pragma interrupt saveall warn" for MSCAN Rx and Tx IRQs (to start with). I'm not a complete novice at interrupt programming, but I am very new to Code Warrior and Motorola chips. Take what I say with a grain of salt unless you reproduce my observations. If I go to P: memory after downloading to RAM, and manually patch the RTS opcode to an RTI opcode ($EDD8 to EDD9, I think), I eliminate the stack corruption and can run IRQs using just the C compiler. This would seem to be a 5.0.2 compiler bug (in my relatively humble opinion and that of one FAE to whom I showed the behavior in person). I've reported it to Metrowerks and they say they are looking for it but have never had it reported before. I guess most people use the SDK. I can sometimes make the behavior toggle by commenting or uncommenting a few lines of code this innocuous: int dummyFunction( int iParam ) { return(0); // I never call this dummy function, but eliminating code until "it works" } // revealed "impossible" compiler behavior The Motorola web site tech support ("Digital DNA") has been helpful, due to Daniel Malik. He felt my mcp might be corrupt since he could make the (intermittent) behavior go away forever with a new project. I've dragged my code into a half-dozen new projects, but if I turn on my usual compiler options, I can 'break' the pragma behavior. (Thanks in advance for the suggestion: "Then don't _do_ that.") I'm currently testing the possibility that some unidentified compiler options make my project 'ISR-RTS-prone" and his not. Daniel Malik uses straight "new project defaults". I used to enable most warnings as errors, and this and that. I followed some manual which cautioned me to disable bool support and wchar-t support and any C++ feature since they were not supported for the '803. I strongly want to use "extended error checking" and "implicit arithmetic conversions" and a few others like deferred inlining and auto-inlining. Another possibility (in my very tentative opinion) is that some interaction with "#pragma called" might matter. I've been stable since I went to all "new project defaults" and only using inline functions from an ISR, never "#pragma called" functions. I'm not going for ultimate speed, just trying to avoid the constraints of the SDK MSCAN driver. Sure, seeing an RTS at the end of your (non-SDK) ISRs is hard to believe, but I have seen it repeatedly though intermittently. Art's code and suggestions (including the app note AN2283/D) have been invaluable. Thank you, Art! I would not have poked the CANRFLG register during SoftReset, or written 0 to the CANTCR during SoftReset, or ever written 0 to the CANTFLG register at all. I tried it your way and my code started working. I bet you hear that a lot. I would follow Art's suggestion to use either the SDK or ASM, except that I would find ASM very difficult beyond a few lines, and just can't use the $3,000 SDK MSCAN application / driver. (I have to change CAN ID's with almost every packet, or else change our design from head to foot.) For now, I'm turning on just a few compiler options at a time, and debugging for a full day each way, to see if the RTIs stay where they belong. Metrowerks has not told me whether they can reproduce my behavior or not, from my project. I will repost soonest if I find how to re-create this oddity with something specific. Thanks for the chance to post. Rick Corey P.S. If you see "madness" on an eval board, not all eval boards have recent silicon. We got one "Proto-A" chip, and some 0111 and 0115 date codes. Check the web site archives for silicon errata. Beware using a SPI peripheral as a Slave on early silicon. Maybe "everyone" knows that already. _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 |
Interrupt/context problem?
Started by ●October 7, 2002
Reply by ●October 9, 20022002-10-09
Reply by ●October 9, 20022002-10-09
|
Jerry,
You are
right of course. I have to avoid the MSCAN driver because we want
different behavior with respect to message IDs.
I
should probably just get over my distrust of the IRQ dispatcher and use that
instead of trying to use #pragma interrupt. Obviously people here are
seeing it work reliably.
Thank
you.
Rick
Corey
|
Reply by ●October 9, 20022002-10-09
|
Without seeing all of the code we can't answer this one for sure, I think most people have already anyway. However, here is some more information to help Understand the pragma assuming C compiler support for bareboard without the facility of the SDK. >My interrupt code has calls to normal function calls, so I have used >#pragma interrupt used in the declarations as specified. You probably need "#pragma interrupt saveall" on ISR, unless all the routine called by this ISR are saving context with "#pragma interrupt called" --#pragma interrupt save/restore only register used by the ISR, a partial context save. Can only call functions with "#pragma interrupt called" to avoid destroying regsiters that are not used/save/restore by the ISR --#pragma interrupt saveall save/restore all registers (except SP/PC), a full context save, you may call any functions from this ISR. This pragma generate code to set default M01/OMR(DSP-140 on targeting manual) --#pragma interrupt called save/restore all register used by this routine (similar to #pragma interrupt), but generates RTS. If this function only make calls to functions that are built with this pragma also, this function is interrupt save and can be called by ISR built with "#pragma interupt" NOTE: default MSL are not built with #pragma interrupt called, so ISR that calls it or call function that eventually use MSL need to use #pragma interupt saveall. Reading manual can be confusing sometimes, for further detail, example projects in 5.0 shows usage of those pragma in isr.c/led.c, it explain briefly on when to use what interrupt pragma. -- Do what you do best and let Metrowerks do the rest !! http://www.metrowerks.com/MW/Services/SSG/default.htm Metrowerks, maker of CodeWarrior - "Software Starts Here" Ron Liechty - - http://www.metrowerks.com |
Reply by ●October 9, 20022002-10-09
|
I've identified two specific checkboxes that "cause" #pragma
interrupt saveall warn to generate RTS instead of RTI, with non-SDK '803 stationary, using 5.0.2 CW. Checking "Auto-inline" plus "deferred inlining" consistently causes RTS to be created in my ISRs. I have some inline functions and one "pragma interrupt called" function called from inside my ISRs, for what that is worth. I've sent screenshots and a zipped project to both Metrowerks and Daniel Malik. If anyone wants the project (63KB zipped) just let me know by Email. The screenshots are verbose, 642 KB even zipped. Interestingly, despite using "saveall warn" in both ISRs, the length of the postamble is quite different in the two ISRs. My guess is that using a "pragma called" function causes the different postambles. Just a guess! (calls one inline and one "pragma interrupt called" function) } // end ISR_CAN_Transmit() P:000002A7: DE1B pop P:000002A8: FD1B move X:(SP)-,N P:000002A9: E040 nop P:000002AA: 9D3B moves N,X:0x003b P:000002AB: FD1B move X:(SP)-,N P:000002AC: E040 nop P:000002AD: 9D3A moves N,X:0x003a P:000002AE: FD1B move X:(SP)-,N P:000002AF: E040 nop P:000002B0: 9D39 moves N,X:0x0039 P:000002B1: FD1B move X:(SP)-,N P:000002B2: E040 nop P:000002B3: 9D38 moves N,X:0x0038 P:000002B4: EDD8 rts (calls one inline function) } // end ISR_CAN_Receive() P:000001FD: 9EFE lea (SP-0x0002) P:000001FE: EDD8 rts For what it is worth (almost nothing), I think I see more odd behavior WRT 'inline' and 'called'. First, I haven't been able to get the linker to find an inline function declared in a file other than where it was called from. Can a linker feature be non-ANSI? (rhetorical) Second: by changing a function from 'inline' to 'pragma called', I can change it's behavior 180 degrees. "Called" seemed more healthy than "inline". I think but am not positive that I confirmed the wrong behavior even when it was called inline from a non-ISR. OK, Metrowerks has explained "inlining" as follows: Inlining occurs in the front-end, in one of the initial phases of the compiler. This means that ISR specific features are not detectable for inlined routines during the backend phase. There is no workaround for this. They would have to turn off inlining. This would be considered a feature request for a future release. The order in which routines are compiled is also very important in order to detect if a warning should be emitted. It is necessary for the ISR would have to be compiled first. This also only works for routines directly called from an ISR and not indirectly called from an ISR. If there is a possibility for a file to indirectly be called from an ISR then the saveall option should be used. I hear: "don't use inline functions in ISRs". Oh! I'm not sure I fully understand the second paragraph, but I see that I should repeat some tests with all inline functions changed to 'pragma called'. Now I'm even more afraid of deferred inlining! I'm almost ready to give up on trying to write IRQ code that I control and understand, and heed the wisdom of the group here: use the SDK dispatcher. I agree that once I buy into the SDK stationary, I can use or avoid the SDK drivers for each individual peripheral. I was trying to avoid the whole SDK, altogether. Mistake. Fear pragma interrupt, or at the very least fear #pragma interrupt saveall warn used with inline functions, auto-inline and/or deferred inlining. Many thanks to everyone sharing their experience here! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
Reply by ●October 12, 20022002-10-12
|
More symptoms related to "#pragma interrupt saveall warn", in a
non-SDK context: Using non-SDK 56803 stationary, and checking the "deferred inlining" checkbox, I always saw RTS at the end of my ISRs, instead of the required RTI. At least once, the sole act of unchecking that box gave me my RTIs back. However, that symptom occurred whether the ISRs called any inline functions at all! I removed every instance of the "inline" keyword from the project, but left the "deferred inlining" box checked. I still got RTSs. I tried removing #pragma interrupt called from the called functions, and only got the compiler warning "Non interrupt function TakeFromTxList ... called by interrupt function" from one out of the three instances of "bad" declarations. I commented out every call to any function from inside any ISR. I still got RTSs as long as the "deferred" checkbox was checked. In every test, all called functions were declared ABOVE the ISRs, so "deferred inlining" was not really needed (especially where there were no inline functions at all in the project). I hade "auto-inline" OFF, but kept the "smart depth" option for these tests. Here is the cutest symptom: Even after commenting out every call to any function from inside any ISR, the compiler still warned me: "Non interrupt function TakeFromTxList ... called by interrupt function" . Seemingly the compiler was looking into a test function declared below my ISRs. The test function was never called by any function whatsoever anywhere (it was a leftover). It did, however make a call to TakeFromTxList(). I am thinking that the compiler must be confused about where the scope of "#pragma interrupt saveall warn" ends, or maybe it is just confused about which functions are ISRs and which are not. Maybe it "skips one function" because the "#pragma interrupt saveall warn" is inside the ISR braces instead of preceding the declaration. In any event, it DID put an "RTI" at the end of my unrelated test function instead of at the end of my ISR! Beware the "deferred inlining checkbox"! Beware "#pragma interrupt saveall warn" ! Rick Corey, Software Development DPC Instrument Systems Division, Flanders NJ |
