We have had problems with the MSCAN error interrupts (as I'm sure
you've already read about), but I developed a work around that fixed the problem. It's described in my message "MSCAN problem" on October 3, 2002. Since fixing that problem, we have been having some program crashes that are associated with a high rate of CAN messages. They are caused by the Hardware Stack Overflow (Vector number 5, Address X:$000A). This is being caused by CodeWarrior placing 'do' instructions in the program, despite the fact that the "Allow DO Instructions" box is unchecked in {Target}->Target Settings Panels->Code Generation->M56800 Processor. Metrowerks is currently working on a solution for this bug. Your problem seems to have a different cause, though. It sounds like you have done all the correct things regarding #pramga interrupt, etc. Although we don't use very much from the SDK, one part we do use (and it works very well) is the Interrupt Dispatcher. If you're not using it, then my description about "Normal", "Fast", and "Super Fast" interrupts doesn't apply to you. Some things to try: 1. Have you checked all your stacks, to see if any of them are close to overflowing? 2. Try disabling interrupts at the beginning of the function, and re-enable them just before the "return" at the end of the function. This may cause problems for other parts of the program (depending on how long it takes the function to execute), but it will tell you absolutely if the pointer corruption is being caused by interrupts that occur during the execution of the function. 3. Inside your function, try saving the pointer to a global memory location, and use the pointer only from this global location. This makes it much simpler to put a watchpoint on it, to see if it is being changed by some other part of the program. This does, however, make the function non-reentrant, so it can be called from only one task. I hope this helps. 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: Monday, October 07, 2002 7:38 AM To: ; Subject: [motoroladsp_unmoderated] Interrupt/context problem? 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 To unsubscribe from this group, send an email to: ">http://docs.yahoo.com/info/terms/ |