Forums

#pragma Interrupt

Started by chandooramkumar May 26, 2005
Hi,

I am trying to program an ISR in MSCAN recieve routine. I went thru
the archives and found a message frm Art Johnson which was regding the
usage of #pragma Interrupt. It will be gr8 if someone culd send me the
J1939_task.c file to refer to ISR programming. I am attachin the
message frm Art BELOW...

Thanks,
Chandru

RE: simple project demonstrating how to set-up interrupts without the
use of SDK
Art Johnson - Oct 9 18:03:00 2002 My opinion is, that the best and safest thing to do regarding the MSCAN
interrupts is to use the SDK Interrupt Dispatcher and "Normal"
interrupts. We
do that here and it works flawlessly. The Interrupt Dispatcher does
use a bit
of extra time to do the full context save and restore, but you are
then freed
from having to use "#pragma interrupt" in all the functions called
from your
ISR. As Bill Hutchings pointed out this morning, this may actually
save time
(and code space) overall, because your functions are not all having to do
partial context saves/restores.

We are using the CAN bus at the 250 kbps rate, and have no problems
regarding
the amount of CPU time used by the MSCAN interrupts.

So, to summarize my recommendations:
1) use the SDK Interrupt Dispatcher and "Normal" interrupts
2) remove the "#pragma interrupt" from all MSCAN functions, INCLUDING
the ISRs

The attached file "J1939_task.c" has the ISRs and the one function that is
called from the Rx ISR. You can see that we don't use "#pragma
interrupt" in
any of them. The Error ISR also contains the work around for the Rx
Warning/Error and Tx Warning/Error interrupt problems that I mentioned in
earlier messages. The function "Activate_Sstask()" is a DSPOS RTOS
function
call; what we have is a "J1939 task" that the interrupts send signals
to, and
which performs the actions determined by which signal(s) it sees.

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


Hi Chandru

I forwarded Art's original post offline. However, if you are working with
the SDK, aren't your tools several years old? Code Warrior is up to version
7.

By the way, all the posts of this group are archived:

Archives: http://www.dsprelated.com/groups/motoroladsp/1.php

- 2nd link, same destination:

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

Often searching the archive will get you much more information, faster, than
waiting for someone to notice your post and then reply.

I would encourage you to share whatever you discover on your chip, with your
test setup and requirements, back with the group, so that we can all learn
from what you learn. Thanks!

Rick Corey

-----Original Message-----
From: motoroladsp@moto... [mailto:motoroladsp@moto...]On
Behalf Of chandooramkumar
Sent: Thursday, May 26, 2005 1:35 PM
To: motoroladsp@moto...
Subject: [motoroladsp] #pragma Interrupt Hi,

I am trying to program an ISR in MSCAN recieve routine. I went thru
the archives and found a message frm Art Johnson which was regding the
usage of #pragma Interrupt. It will be gr8 if someone culd send me the
J1939_task.c file to refer to ISR programming. I am attachin the
message frm Art BELOW...

Thanks,
Chandru

RE: simple project demonstrating how to set-up interrupts without the
use of SDK
Art Johnson - Oct 9 18:03:00 2002 My opinion is, that the best and safest thing to do regarding the MSCAN
interrupts is to use the SDK Interrupt Dispatcher and "Normal"
interrupts. We
do that here and it works flawlessly. The Interrupt Dispatcher does
use a bit
of extra time to do the full context save and restore, but you are
then freed
from having to use "#pragma interrupt" in all the functions called
from your
ISR. As Bill Hutchings pointed out this morning, this may actually
save time
(and code space) overall, because your functions are not all having to do
partial context saves/restores.

We are using the CAN bus at the 250 kbps rate, and have no problems
regarding
the amount of CPU time used by the MSCAN interrupts.

So, to summarize my recommendations:
1) use the SDK Interrupt Dispatcher and "Normal" interrupts
2) remove the "#pragma interrupt" from all MSCAN functions, INCLUDING
the ISRs

The attached file "J1939_task.c" has the ISRs and the one function that is
called from the Rx ISR. You can see that we don't use "#pragma
interrupt" in
any of them. The Error ISR also contains the work around for the Rx
Warning/Error and Tx Warning/Error interrupt problems that I mentioned in
earlier messages. The function "Activate_Sstask()" is a DSPOS RTOS
function
call; what we have is a "J1939 task" that the interrupts send signals
to, and
which performs the actions determined by which signal(s) it sees.

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



Hi Chandru
 
What version of Code Warrior are you using?  All we used from the SDK back then was the interrupt dispatcher for the 56803. 
 
If you are having trouble with interrupts, CANbus is a difficult place to start.  Why not practice by toggling an LED on a simple timer interrupt?  The code to configure a timer is only around 5-10 lines, plus playing with appconfig.h.
 
 
>> Is there a way to check if message is copied onto the Background receive buffers?? <<
 
Maybe I don't understand the question.
 
There is an RX Buffer full flag (RXF) - bit0 in CANRFLG register (section 8.8.5.9 in the Peripheral Users Manual).
 
I would be careful to increment some data byte in each packet I sent, so that you can tell if you are missing any. 
 
Remember that you mostly can not use breakpoints when debugging interrupt service routines!  After the CPU stops at the first breakpoint, things may keep happening, and overruns will happen.  If you are only looping back, you might get away with it, but don't be surprised if "bad things happen".
 
Also, double-check each register.  If some flag changes state just because you  READ  the register, you can not afford to  LOOK  at that register with the debugger.  The debugger will read it in order to display its contents, the "read" will clear the flag, and you will wonder where all your data went.
 
 
If you need to debug receiving multiple packets, take the time to write a function that puts some data from each packet into a RAM array, and increment the array index.  Even one byte would be enough.  Then, put your breakpoint on some test that looks for "array full" or "got second packet". 
 
Or, you might send one packet every 3 seconds, and toggle an LED each time you  RECEIVE  one packet.
 
 
>> Is there a way to check if message is copied onto the Background receive buffers?? <<
 
It has been a few years, but here is how I  ~think~  it worked.  Look at Figure 8.4, the register map (page 8-10 on my version).  There is a Foreground Receive Buffer, but no background receive buffer.  I think the "background receive buffer" is really the shift register that grabs bits directly off the wire, and that was Motorola's idea of "double buffered".  When you clear the RX Flag, the peripheral quickly swaps the  "background receive buffer"  with the Foreground Receive Buffer.  I seem to recall the SCI port (RS-232) worked that way, too.  Think of it as a single buffer that can fill back up "really fast".
 
In any event, you can never read the  "background receive buffer".  Just read the foreground and clear the flag (RXF).  If the  "background receive buffer" has complete data, the flag will become set again right away and you can grab another buffer-full.
 
However - try to stay ahead of it instead of trying to catch two packets with one interrupt - I think you invite overruns if you ever let both buffers become full. 
 
Are you using loopback?
 
>> Ideally a transmit buffer empty interrupt shld be generated here. I have placed the #pragma interrupt in the receive routine to catch this interrupt.   <<
 
I always used the TX interrupt to fill the TX buffer, and the RX interrupt to read from the RX buffer.  I would try to use both and not combine them, unless you are only using CANbus in loopback mode!
 
Good luck!
 
Rick Corey
 
P.S.  Be sure to read the date code off your DSP, and look at the errata sheets from the Freescale website.  CAN was pretty good, pretty early, I think.  SPIbus stunk badly for many revs of the chip!
 
-----Original Message-----
From: Chandrasekar Ramkumar [mailto:c...@gmail.com]
Sent: Wednesday, June 01, 2005 4:44 PM
To: Corey, Rick
Subject: Re: [motoroladsp] #pragma Interrupt

Hi Rick,

Thanks for the mail. I m currently working only with codewarrior. However i was looking into those programs as example to program ISR's. I am still working on the MSCAN problem. Now i am able to transmit the data. I am able to clear the TXE0(Transmit buffer 0 status flag) when i store data in the buffer and then MSCAN sets it to 1. Ideally a transmit buffer empty interrupt shld be generated here. I have placed the #pragma interrupt in the receive routine to catch this interrupt.
Is there a way to check if message is copied onto the Background receive buffers??
Any sort of help in this will be great.

sorry to trouble u again.

Chandru

On 5/26/05, Corey, Rick <R...@dpconline.com> wrote:
Hi Chandru

I forwarded Art's original post offline.  However, if you are working with
the SDK, aren't your tools several years old?  Code Warrior is up to version
7.

By the way, all the posts of this group are archived:

        Archives:  http://www.dsprelated.com/groups/motoroladsp/1.php

-  2nd link, same destination:

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

Often searching the archive will get you much more information, faster, than
waiting for someone to notice your post and then reply.

I would encourage you to share whatever you discover on your chip, with your
test setup and requirements, back with the group, so that we can all learn
from what you learn.  Thanks!

Rick Corey

-----Original Message-----
From: m...@yahoogroups.com [mailto:m...@yahoogroups.com]On
Behalf Of chandooramkumar
Sent: Thursday, May 26, 2005 1:35 PM
To: m...@yahoogroups.com
Subject: [motoroladsp] #pragma InterruptHi,

I am trying to program an ISR in MSCAN recieve routine. I went thru
the archives and found a message frm Art Johnson which was regding the
usage of #pragma Interrupt. It will be gr8 if someone culd send me the
J1939_task.c file to refer to ISR programming. I am attachin the
message frm Art BELOW...

Thanks,
Chandru

RE: simple project demonstrating how to set-up interrupts without the
use of SDK
Art Johnson - Oct 9 18:03:00 2002My opinion is, that the best and safest thing to do regarding the MSCAN
interrupts is to use the SDK Interrupt Dispatcher and "Normal"
interrupts. We
do that here and it works flawlessly. The Interrupt Dispatcher does
use a bit
of extra time to do the full context save and restore, but you are
then freed
from having to use "#pragma interrupt" in all the functions called
from your
ISR. As Bill Hutchings pointed out this morning, this may actually
save time
(and code space) overall, because your functions are not all having to do
partial context saves/restores.

We are using the CAN bus at the 250 kbps rate, and have no problems
regarding
the amount of CPU time used by the MSCAN interrupts.

So, to summarize my recommendations:
1) use the SDK Interrupt Dispatcher and "Normal" interrupts
2) remove the "#pragma interrupt" from all MSCAN functions, INCLUDING
the ISRs

The attached file "J1939_task.c" has the ISRs and the one function that is
called from the Rx ISR. You can see that we don't use "#pragma
interrupt" in
any of them. The Error ISR also contains the work around for the Rx
Warning/Error and Tx Warning/Error interrupt problems that I mentioned in
earlier messages. The function "Activate_Sstask()" is a DSPOS RTOS
function
call; what we have is a "J1939 task" that the interrupts send signals
to, and
which performs the actions determined by which signal(s) it sees.

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

------------------------ Yahoo! Groups Sponsor --------------------~-->
What would our lives be like without music, dance, and theater?
Donate or volunteer in the arts today at Network for Good!
http://us.click.yahoo.com/Tcy2bD/SOnJAA/cosFAA/PNArlB/TM
--------------------------------~-

--
Chandru Ramkumar,
828 S Claremont Ave,Apt#1
Chicago-IL 60612