Forums

RE: [motoroladsp_unmoderated] Interrupt/context problem?

Started by Art Johnson October 7, 2002
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/