Forums

Interrupt/context problem?

Started by Jarrid Gross October 7, 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



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



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/> .


Attachment (not stored)
dispatcher.asm
Type: application/octet-stream

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



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/


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



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.


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/


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:r...@dpconline.com]
Sent: Tuesday, October 08, 2002 5:26 PM
To: 'm...@yahoogroups.com'
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:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


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.
-----Original Message-----
From: Johnson, Jerry [mailto:j...@giddings.com]
Sent: Wednesday, October 09, 2002 9:55 AM
To: 'Corey, Rick'; m...@yahoogroups.com
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:r...@dpconline.com]
Sent: Tuesday, October 08, 2002 5:26 PM
To: 'm...@yahoogroups.com'
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:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


_____________________________________
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:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.