Sign in
Search motoroladsp
Subscribe to motoroladsp
motoroladsp by Keywords
56303 | 563xx | 5680 | 56805 | 5680x | 56F80 | 56F800DEMO | 56F805 | 56f807 | 56F830 | ADC | Bootloader | Codec | CodeWarrior | CW5 | CW6 | Debugger | DSP56303 | DSP56303EVM | DSP563xx | DSP5680 | DSP56800 | DSP56807 | DSP56858 | DSP56858EVM | DSP56F803 | DSP56F805 | DSP56F807 | DSP56F80x | DSP56F826 | DSP56F827 | DSP56F8xx | EVM | FFT | Flash_over_jtag | GPIO | Interrupt | Interrupts | JTAG | LCD | Linker | MCF5307 | Metrowerks | Modulus | MSCAN | PCMaster | PWM | Quad | Rif | RTOS | SDK | SPI
Discussion Groups
Discussion Groups | Freescale DSPs | Interrupt/context problem?
Technical discussions about Freescale (Motorola) DSPs (including the DSP56000, DSP56300, DSP56600, 56800 DSPs).
Interrupt/context problem? - Jarrid Gross - Oct 7 14:37:00 2002
|
I have been having some tough problems all along, and had hoped that upgrading to CW5.0 + 5.02 patch would cure me, but it didnt... Heres what happens. uint32 bogie_call(float * flt_arg_ptr, uint32 long_arg) { float f; f = 100; // lots of code... // some floating point usage // makes this section a significant percentage // the background loop timing. *flt_arg_ptr = f; // sometimes writes into outerspace (an important variable that causes a crash) } The above is a simplification of the code that was executing, when a watchpoint to a write to an unrelated value ocurred. the corruption always "it seems" occurs when the value that is pointed to is written. Looks as if the pointer was altered prior to usage. I can get the code to fail usually in about 5 seconds by flooding cpu with CAN messages at the rate of about 1000 per second. Sending a lower rate of CAN messages makes the crash take longer to occur, but I am convinced that probably any interrupt could cause the problem because I am pretty sure that another "bug" in my code can best be explained by the same circumstances. I have been paying attention to the Recent posts by Art on intterupts, and havnt run across 'fast ints' in the documentation. Please elaborate. I also read read the CW section on #pragma interrupt. I have always had #pragma interrupt at the top of all my ISRs. I converted all my ISRs to include: void myisr(void) { #pragma interrupt warn } The recompiled everything and found all the usage of non-protected calls. I then added #pragma interrupt used before each of the prototype decarations just like shown in the manual. Still didnt work. Also tried #pragma interrupt saveall But it wanted a library, which the manual didnt tell us about. Ran out of time before trying it out further. Lastly I am NOT using the SDK. I have had enough problems with MOT documentation over the years that I figured I could do without thier code too. Hope someone out there can slap me around. TIA |
|
|
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: Interrupt/context problem? - Jarrid Gross - Oct 8 18:51:00 2002
|
I have determined that interrupts definately are causing my corruption (read below). I really had hoped that someone from Metrowerks would step up to the plate and splain to me/us what costitutes a full/protected context save, and how it releates to the #pragma interrupt. Is this a candidate for a problem report, or have I overlooked something? Sorry Metrowerks, your manual does not properly explain this topic. My interrupt code has calls to normal function calls, so I have used #pragma interrupt used in the declarations as specified. Why then does it appear that the compiler is not doing a full context restore in the iterrupt(s)? What registers need to be saved/restored, and what procedures need to be implimented (so I can look at the disassembly) and verify that the compiler is doing what I want? This seems like a rather critical technical point, and certainly worthy of more than 2.5 obscure pages in the compiler manual. TIA > I have been having some tough problems all along, and had hoped that > upgrading to CW5.0 + 5.02 patch would cure me, but it didnt... > Heres what happens. > uint32 bogie_call(float * flt_arg_ptr, uint32 long_arg) > { > float f; > f = 100; > > // lots of code... > // some floating point usage > // makes this section a significant percentage > // the background loop timing. > > *flt_arg_ptr = f; // sometimes writes into outerspace (an important > variable that causes a crash) > } > The above is a simplification of the code that was executing, when a > watchpoint to a write > to an unrelated value ocurred. the corruption always "it seems" occurs > when the value that is pointed > to is written. Looks as if the pointer was altered prior to usage. > > I can get the code to fail usually in about 5 seconds by flooding cpu > with CAN messages > at the rate of about 1000 per second. Sending a lower rate of CAN > messages makes the > crash take longer to occur, but I am convinced that probably any > interrupt could cause > the problem because I am pretty sure that another "bug" in my code can > best be explained > by the same circumstances. > I have been paying attention to the Recent posts by Art on intterupts, > and > havnt run across 'fast ints' in the documentation. Please elaborate. > I also read read the CW section on #pragma interrupt. > > I have always had #pragma interrupt at the top of all my ISRs. > > I converted all my ISRs to include: > void myisr(void) > { > #pragma interrupt warn > } > > The recompiled everything and found all the usage of non-protected > calls. > I then added > #pragma interrupt used before each of the prototype decarations just > like shown in > the manual. > > Still didnt work. > > Also tried > #pragma interrupt saveall > > But it wanted a library, which the manual didnt tell us about. > Ran out of time before trying it out further. > > Lastly I am NOT using the SDK. > I have had enough problems with MOT documentation over the years that > I figured I could do without thier code too. > Hope someone out there can slap me around. > TIA |
|
|
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Hutchings William-p23437 - Oct 8 20:34:00 2002
|
M. Gross - A couple of things on the #pragma interrupt. The #pragma interrupt can be effective at lowering the overhead of a C ISR because it will only save and restore only the registers used in the function. But if you have other function calls you must define them with #pragma interrupt. And each function is not aware of the what has been saved at the previous level. So if you have a few function calls you could be saving and restoring registers several times over and incurring more overhead than if you just performed a complete context save at the beginning of the ISR. So using #pragma interrupt is not always the most optimal choice. In the past I have found that using #pragma interrupt did not always create code that operated properly. If I suspected the #pragma interrupt code generation I would use the SDK interrupt services to give a guaranteed proper context save. If the #pragma interrupt was the issue then the problem would get fixed. I reccommend using the SDK stationary as the starting point and using the interrupt services to get yourself on firm ground. Or you can also just use the dispatcher code as a template as to what needs to be saved. I have attached it. Look at the Dispatcher routine. This is the maximum context save. Thanks. - Bill -----Original Message----- From: Jarrid Gross [mailto:] Sent: Tuesday, October 08, 2002 11:51 AM To: Subject: [motoroladsp] RE: Interrupt/context problem? I have determined that interrupts definately are causing my corruption (read below). I really had hoped that someone from Metrowerks would step up to the plate and splain to me/us what costitutes a full/protected context save, and how it releates to the #pragma interrupt. Is this a candidate for a problem report, or have I overlooked something? Sorry Metrowerks, your manual does not properly explain this topic. My interrupt code has calls to normal function calls, so I have used #pragma interrupt used in the declarations as specified. Why then does it appear that the compiler is not doing a full context restore in the iterrupt(s)? What registers need to be saved/restored, and what procedures need to be implimented (so I can look at the disassembly) and verify that the compiler is doing what I want? This seems like a rather critical technical point, and certainly worthy of more than 2.5 obscure pages in the compiler manual. TIA > I have been having some tough problems all along, and had hoped that > upgrading to CW5.0 + 5.02 patch would cure me, but it didnt... > Heres what happens. > uint32 bogie_call(float * flt_arg_ptr, uint32 long_arg) > { > float f; > f = 100; > > // lots of code... > // some floating point usage > // makes this section a significant percentage > // the background loop timing. > > *flt_arg_ptr = f; // sometimes writes into outerspace (an important > variable that causes a crash) > } > The above is a simplification of the code that was executing, when a > watchpoint to a write > to an unrelated value ocurred. the corruption always "it seems" occurs > when the value that is pointed > to is written. Looks as if the pointer was altered prior to usage. > > I can get the code to fail usually in about 5 seconds by flooding cpu > with CAN messages > at the rate of about 1000 per second. Sending a lower rate of CAN > messages makes the > crash take longer to occur, but I am convinced that probably any > interrupt could cause > the problem because I am pretty sure that another "bug" in my code can > best be explained > by the same circumstances. > I have been paying attention to the Recent posts by Art on intterupts, > and > havnt run across 'fast ints' in the documentation. Please elaborate. > I also read read the CW section on #pragma interrupt. > > I have always had #pragma interrupt at the top of all my ISRs. > > I converted all my ISRs to include: > void myisr(void) > { > #pragma interrupt warn > } > > The recompiled everything and found all the usage of non-protected > calls. > I then added > #pragma interrupt used before each of the prototype decarations just > like shown in > the manual. > > Still didnt work. > > Also tried > #pragma interrupt saveall > > But it wanted a library, which the manual didnt tell us about. > Ran out of time before trying it out further. > > Lastly I am NOT using the SDK. > I have had enough problems with MOT documentation over the years that > I figured I could do without thier code too. > Hope someone out there can slap me around. > TIA Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=233351.2428261.3848243.2225242/D=egroupweb/S=1705771855:H\ M/A=1212978/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_youH1/g22lp?Target=mm/g\ 22lp.tmpl> <http://us.adserver.yahoo.com/l?M=233351.2428261.3848243.2225242/D=egroupmail/S=\ :HM/A=1212978/rand=747295538> _____________________________________ /groups.php3 <http://www.dsprelated.com/groups.php3 > . | |||
|
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
Re: RE: Interrupt/context problem? - MW Ron - Oct 8 20:58:00 2002
|
Hi Jarrid, I'll see if I can find someone to address this issue. I don't know if there is enough information here but we can try. Did you send this in as a bug? Ron > I have determined that interrupts definately are causing my > corruption (read below). > > I really had hoped that someone from Metrowerks would step up to the > plate and splain to me/us what costitutes a full/protected context > save, and how it releates to the #pragma interrupt. > Is this a candidate for a problem report, or have I overlooked something? > > Sorry Metrowerks, your manual does not properly explain this topic. > > My interrupt code has calls to normal function calls, so I have used > #pragma interrupt used in the declarations as specified. > > Why then does it appear that the compiler is not doing a full context > restore in the iterrupt(s)? > > What registers need to be saved/restored, and what procedures need > to be implimented (so I can look at the disassembly) and verify that > the compiler is doing what I want? > > This seems like a rather critical technical point, and certainly > worthy of more than 2.5 obscure pages in the compiler manual. > > TIA > >> I have been having some tough problems all along, and had hoped that >> upgrading to CW5.0 + 5.02 patch would cure me, but it didnt... >> >> >> Heres what happens. >> >> >> uint32 bogie_call(float * flt_arg_ptr, uint32 long_arg) >> { >> float f; >> f = 100; >> >> // lots of code... >> // some floating point usage >> // makes this section a significant percentage >> // the background loop timing. >> >> *flt_arg_ptr = f; // sometimes writes into outerspace (an > important >> variable that causes a crash) >> } >> >> >> The above is a simplification of the code that was executing, when a >> watchpoint to a write >> to an unrelated value ocurred. the corruption always "it seems" > occurs >> when the value that is pointed >> to is written. Looks as if the pointer was altered prior to usage. >> >> I can get the code to fail usually in about 5 seconds by flooding > cpu >> with CAN messages >> at the rate of about 1000 per second. Sending a lower rate of CAN >> messages makes the >> crash take longer to occur, but I am convinced that probably any >> interrupt could cause >> the problem because I am pretty sure that another "bug" in my code > can >> best be explained >> by the same circumstances. >> >> >> I have been paying attention to the Recent posts by Art on > intterupts, >> and >> havnt run across 'fast ints' in the documentation. Please > elaborate. >> >> >> I also read read the CW section on #pragma interrupt. >> >> I have always had #pragma interrupt at the top of all my ISRs. >> >> I converted all my ISRs to include: >> void myisr(void) >> { >> #pragma interrupt warn >> } >> >> The recompiled everything and found all the usage of non-protected >> calls. >> I then added >> #pragma interrupt used before each of the prototype decarations just >> like shown in >> the manual. >> >> Still didnt work. >> >> Also tried >> #pragma interrupt saveall >> >> But it wanted a library, which the manual didnt tell us about. >> Ran out of time before trying it out further. >> >> Lastly I am NOT using the SDK. >> I have had enough problems with MOT documentation over the years > that >> I figured I could do without thier code too. >> >> >> Hope someone out there can slap me around. >> >> >> TIA > > > _____________________________________ > /groups.php3 -- 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 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Art Johnson - Oct 8 21:06:00 2002
|
What we do here, and it works perfectly in all our applications, is this: 1) If it is NOT critical to have a very short execution time for the interrupt, we use the SDK Interrupt Dispatcher with a "Normal" interrupt. The SDK Interrupt Dispatcher saves and restores ALL registers for "Normal" interrupts. 2) If it IS critical to have a very short execution time for the interrupt, we use a "Super Fast" interrupt, which we always write in assembler. The interrupt vector points directly to your ISR function, so the SDK Interrupt Dispatcher is completely bypassed. You must also save and restore all registers explicitly in your code. 3) I would NOT recommend using a "Fast" interrupt, as it does not save/restore all registers. The on-line documentation for the SDK Interrupt Dispatcher is really quite excellent, basically I just read it, tried it, and everything worked the first time. You can start the SDK on-line documentation as follows: Start Programs Motorola Embedded SDK 2.5 Help and Documentation In "Contents", go to: Motorola Embedded SDK Core Documentation SDK Programmer's Guide 7 Interrupts Section 7.2.1 explains the differences between the 3 types of ISRs. Section 7.2.6 describes the SDK Interrupt Dispatcher. Section 7.2.8.3 describes using "#pragma interrupt" with the SDK Interrupt Dispatcher. Also look at Section 7.5.1 "Using Pragma Interrupt". I hope this helps, please let me know if you have any more questions. 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: Jarrid Gross [mailto:] Sent: Tuesday, October 08, 2002 11:51 AM To: Subject: [motoroladsp] RE: Interrupt/context problem? I have determined that interrupts definately are causing my corruption (read below). I really had hoped that someone from Metrowerks would step up to the plate and splain to me/us what costitutes a full/protected context save, and how it releates to the #pragma interrupt. Is this a candidate for a problem report, or have I overlooked something? Sorry Metrowerks, your manual does not properly explain this topic. My interrupt code has calls to normal function calls, so I have used #pragma interrupt used in the declarations as specified. Why then does it appear that the compiler is not doing a full context restore in the iterrupt(s)? What registers need to be saved/restored, and what procedures need to be implimented (so I can look at the disassembly) and verify that the compiler is doing what I want? This seems like a rather critical technical point, and certainly worthy of more than 2.5 obscure pages in the compiler manual. TIA > I have been having some tough problems all along, and had hoped that > upgrading to CW5.0 + 5.02 patch would cure me, but it didnt... > Heres what happens. > uint32 bogie_call(float * flt_arg_ptr, uint32 long_arg) > { > float f; > f = 100; > > // lots of code... > // some floating point usage > // makes this section a significant percentage > // the background loop timing. > > *flt_arg_ptr = f; // sometimes writes into outerspace (an important > variable that causes a crash) > } > The above is a simplification of the code that was executing, when a > watchpoint to a write > to an unrelated value ocurred. the corruption always "it seems" occurs > when the value that is pointed > to is written. Looks as if the pointer was altered prior to usage. > > I can get the code to fail usually in about 5 seconds by flooding cpu > with CAN messages > at the rate of about 1000 per second. Sending a lower rate of CAN > messages makes the > crash take longer to occur, but I am convinced that probably any > interrupt could cause > the problem because I am pretty sure that another "bug" in my code can > best be explained > by the same circumstances. > I have been paying attention to the Recent posts by Art on intterupts, > and > havnt run across 'fast ints' in the documentation. Please elaborate. > I also read read the CW section on #pragma interrupt. > > I have always had #pragma interrupt at the top of all my ISRs. > > I converted all my ISRs to include: > void myisr(void) > { > #pragma interrupt warn > } > > The recompiled everything and found all the usage of non-protected > calls. > I then added > #pragma interrupt used before each of the prototype decarations just > like shown in > the manual. > > Still didnt work. > > Also tried > #pragma interrupt saveall > > But it wanted a library, which the manual didnt tell us about. > Ran out of time before trying it out further. > > Lastly I am NOT using the SDK. > I have had enough problems with MOT documentation over the years that > I figured I could do without thier code too. > Hope someone out there can slap me around. > TIA _____________________________________ /groups.php3 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
Re: RE: Interrupt/context problem? - MW Ron - Oct 8 21:22:00 2002
|
Hi, I talked to engineering support and they would like something more to go on, they can't reproduce it and would like to see more and your project settings. also I've been following what Art has said and he seems to have the solution. If this isn't satisfactory please le me know. Did you want me to put in a bug on Docs none the less just e-mail me privately if you do. Ron > I have determined that interrupts definately are causing my > corruption (read below). > > I really had hoped that someone from Metrowerks would step up to the > plate and splain to me/us what costitutes a full/protected context > save, and how it releates to the #pragma interrupt. > Is this a candidate for a problem report, or have I overlooked something? > > Sorry Metrowerks, your manual does not properly explain this topic. > > My interrupt code has calls to normal function calls, so I have used > #pragma interrupt used in the declarations as specified. > > Why then does it appear that the compiler is not doing a full context > restore in the iterrupt(s)? > > What registers need to be saved/restored, and what procedures need > to be implimented (so I can look at the disassembly) and verify that > the compiler is doing what I want? > > This seems like a rather critical technical point, and certainly > worthy of more than 2.5 obscure pages in the compiler manual. > > TIA > >> I have been having some tough problems all along, and had hoped that >> upgrading to CW5.0 + 5.02 patch would cure me, but it didnt... >> >> >> Heres what happens. >> >> >> uint32 bogie_call(float * flt_arg_ptr, uint32 long_arg) >> { >> float f; >> f = 100; >> >> // lots of code... >> // some floating point usage >> // makes this section a significant percentage >> // the background loop timing. >> >> *flt_arg_ptr = f; // sometimes writes into outerspace (an > important >> variable that causes a crash) >> } >> >> >> The above is a simplification of the code that was executing, when a >> watchpoint to a write >> to an unrelated value ocurred. the corruption always "it seems" > occurs >> when the value that is pointed >> to is written. Looks as if the pointer was altered prior to usage. >> >> I can get the code to fail usually in about 5 seconds by flooding > cpu >> with CAN messages >> at the rate of about 1000 per second. Sending a lower rate of CAN >> messages makes the >> crash take longer to occur, but I am convinced that probably any >> interrupt could cause >> the problem because I am pretty sure that another "bug" in my code > can >> best be explained >> by the same circumstances. >> >> >> I have been paying attention to the Recent posts by Art on > intterupts, >> and >> havnt run across 'fast ints' in the documentation. Please > elaborate. >> >> >> I also read read the CW section on #pragma interrupt. >> >> I have always had #pragma interrupt at the top of all my ISRs. >> >> I converted all my ISRs to include: >> void myisr(void) >> { >> #pragma interrupt warn >> } >> >> The recompiled everything and found all the usage of non-protected >> calls. >> I then added >> #pragma interrupt used before each of the prototype decarations just >> like shown in >> the manual. >> >> Still didnt work. >> >> Also tried >> #pragma interrupt saveall >> >> But it wanted a library, which the manual didnt tell us about. >> Ran out of time before trying it out further. >> >> Lastly I am NOT using the SDK. >> I have had enough problems with MOT documentation over the years > that >> I figured I could do without thier code too. >> >> >> Hope someone out there can slap me around. >> >> >> TIA > > > _____________________________________ > /groups.php3 -- 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 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Corey, Rick - Oct 8 22:25:00 2002
|
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. |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Art Johnson - Oct 9 12:19:00 2002
|
Thanks, Rick, for this very good information. I too have tried (and given up) using "#pragma interrupt" ISRs directly (ie without going through the SDK Interrupt Dispatcher). Bizarre things kept happening, and now I see why. You should know that the only parts of the SDK we use here are the startup code and the Interrupt Dispatcher. We don't use any of the SDK device drivers, we wrote all of our own drivers for the on-chip peripherals (including the MSCAN stuff). This way we get exactly what we need, without the overhead of something that handles all possible options. This is not to criticize the SDK stuff, I look at it as an excellent learning tool, but not something I would use for our own production code. Regarding CodeWarrior, we have seen so many strange and bizarre things that we have been forced to take an "extreme defensive programming" posture here. Which is to say, we break big equations down into many lines of smaller equations, put in parentheses everywhere (even when not technically required), and (as much as possible) add global variables to show us what is happening throughout our programs. Defensive programming is a very good idea anyway, but in my (not-so-humble) opinion using CodeWarrior makes it an absolute necessity. Again, thanks very much for this highly informative post, and keep them coming! 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: Corey, Rick [mailto:] Sent: Tuesday, October 08, 2002 3: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. _____________________________________ /groups.php3 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Johnson, Jerry - Oct 9 16:54:00 2002
|
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.
|
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Hutchings William-p23437 - Oct 9 17:08:00 2002
|
The SDK 2.5
fully supports using your own MSCAN driver. It is like any of the other drivers in that you
select whether you want to include it or not. The premium MSCAN driver is simply offered as a
option to customers who do not wish to write their own driver.
|
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Art Johnson - Oct 9 17:16:00 2002
|
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. _____________________________________ /groups.php3 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. Yahoo! Groups Sponsor ADVERTISEMENT _____________________________________ /groups.php3 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Corey, Rick - Oct 9 18:28:00 2002
|
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
|
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
Re: Interrupt/context problem? - MW Ron - Oct 9 20:32:00 2002
|
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 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Corey, Rick - Oct 9 21:37:00 2002
|
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 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )
RE: RE: Interrupt/context problem? - Corey, Rick - Oct 12 14:22:00 2002
|
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 |
(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )