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 |
|
Interrupt/context problem?
Started by ●October 7, 2002
Reply by ●October 8, 20022002-10-08
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 |
|
Reply by ●October 8, 20022002-10-08
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 <http://rd.yahoo.com/M#3351.2428261.3848243.2225242/D=egroupweb/S05771855:H\ M/A12978/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#3351.2428261.3848243.2225242/D=egroupmail/S=\ :HM/A12978/randt7295538> _____________________________________ 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 <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> . | |||
|
Reply by ●October 8, 20022002-10-08
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 > > > _____________________________________ > 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 > ">http://docs.yahoo.com/info/terms/ -- 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 8, 20022002-10-08
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 _____________________________________ 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 ">http://docs.yahoo.com/info/terms/ |
Reply by ●October 8, 20022002-10-08
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 > > > _____________________________________ > 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 > ">http://docs.yahoo.com/info/terms/ -- 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 8, 20022002-10-08
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. |
Reply by ●October 9, 20022002-10-09
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. _____________________________________ 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 ">http://docs.yahoo.com/info/terms/ |
Reply by ●October 9, 20022002-10-09
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.
|
Reply by ●October 9, 20022002-10-09
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.
|