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-----Hi Rick,
From: Chandrasekar Ramkumar [mailto:c...@gmail.com]
Sent: Wednesday, June 01, 2005 4:44 PM
To: Corey, Rick
Subject: Re: [motoroladsp] #pragma Interrupt
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