68300

Jeff -

Thanks for getting back to me.  Initially I was hoping to find that 
we were indeed overwriting other channel's bits when clearing the 
IFLAG, since it would explain everything and would be easy to fix, 
but I stepped through it with the debugger ASM line by ASM line and 
it looks okay.  Then I thought that a Tx might be happening while I 
was in the middle of the Rx ISR and mess up the reading-writing of 
the IFLAG, but my understanding is that an interrupt of equal 
priority will not be recognized while in an ISR.  Just in case, I 
surrounded the IFLAG register reading-writing logic with total INT 
disable/enables, but it made no difference.

Now as to your question about the Tx polling - nice shot.  When we 
were in design phase the engineer who wrote this code claimed the Tx 
was pollable because she understood the Message Buffer Code would 
indicate BUSY/READY as it did for the Rx.  It occurred to me only 
yesterday to stop reading about the Rx so much and look at the Tx, 
where I found that, at least in the manual I have (MC68336/376UM/AD), 
the code in a Tx buffer changes from a 0x1000 to ----- (according to 
the manual's table) upon successful transmission - which I take to 
mean nothing that can be polled for (unless someone out there knows 
what ---- means).  Apparently the engineer came to the same 
conclusion and polled what the manual suggested - the IFLAG.  
Unfortunately, as you have noted, that is already cleared by the Tx 
INT, so to get the code to work the result of that bit check is 
ignored.

So apparently the Tx routine stuffs the message buffer whenever it 
feels like it.  What has made it 'work' this long is that we only 
send replies (Tx) to messages we receive, and we receive them more 
than 1 msec apart, so a conflict never arises.

Obviously I have to fix the Tx - to minimize the surgery I would like 
to poll still, so if I poll the IFLAG, how do I 'seed' the process to 
get that first Tx ISR?  Is there a clever way or do I just send out a 
message somewhere on startup?

Also, does this explain the original overstuffed Rx problem?  I don't 
see how - unless somehow a collision on the Tx channel spills over 
into the Rx.

We are using channel#0 for general Tx, channel#1 for Rx, channel#2 
for Rx (configured the same as channel#1), channel#13 for Tx, and 
channel#14 for Rx.  Channels 0&1 are the main players here, 13&14 are 
for special IDs that aren't sent yet, and channel#2 was intended to 
be used if the traffic increased so channel#1 got overstuffed.  But 
watching traffic on the CAN bus indicates traffic isn't a factor in 
this.  We disabled all channels but 0&1 and there was no difference.

I appreciate the time you're spending on this.

Thanks

--John 


--- In 68300@yahoogroups.com, jeffrey.tenney@g... wrote:
> John,
> 
> One thing that struck me from your description is that you "clear" 
the 
> IFLAG register.  Do you mean that you clear just the one bit 
representing 
> the empty Tx buffer?  If you're clearing the entire register, that 
may be 
> your problem.  (You could be missing an Rx interrupt.)
> 
> Also, I don't understand how your Tx side can work.  You respond 
> asynchronously to a Tx interrupt by simpling clearing the flag. 
> Synchronously, what condition are you polling for to tell you it's 
OK to 
> transmit?
> 
> Finally, how many MBs are you using as Tx, how many as Rx, and 
which MB 
> numbers for which?  Is any of your Rx buffers filtering in a way 
that it 
> could receive your own transmissions?
> 
> Jeff
> 
> 
> 
> 
> 
> "agawam1964" <agawam1964@y...>
> 10/23/2003 05:05 AM
> Please respond to 68300
> 
>  
>         To:     68300@yahoogroups.com
>         cc: 
>         Subject:        [68300] TouCAN Dropping Messages
> 
> 
> I have five MC68376 systems communicating with a host PC via CAN 
> using a proprietary protocol.  We're running at 125Kbaud.  One 
> channel is Rx, one channel is Tx.  The Tx we more or less use in a 
> syncronous (polled) mode, with the Tx interrupt basically just 
> clearing the IFLAG register.  The Rx is normal interrupt driven.
> 
> For the most part everything is running smoothly.  Most of the CAN 
> traffic occurs in bursts separated by several seconds, which all 
five 
> systems weather without incident.  However, the host (Dell XP 
system) 
> needs to poll one system at a rate of about 10 hz, and every 100 
> seconds or so I'll get the Rx Buffer overrun error on that system.
> 
> I instrumented the ISRs to toggle an I/O pin and found that the Rx 
> ISR is 500 usec.  The Rx ISR where the error is dectected doesn't 
> seem to occur in heavy traffic; typically the prior ISR occurs a 
few 
> msec before - definately no overlap with prior Rx or Tx ISRs. 
> 
> To help debug this I moved all other ISRs to a lower priority INT, 
> including the heartbeat PIT, with no noticeable effect.  My past 
> experience suggests to me I'm not locking-reading-clearing the 
> buffers and registers correctly, but I've reread the manual about n 
> hundred times and can't see where I'm going wrong.  Is there some 
> subtlety about reading the TouCAN registers and buffers that isn't 
in 
> the manual?
> 
> --John
> 
> 
> 
> ---------------------------------------------------
> To unsubscribe from this group, send an email to:
> 68300-unsubscribe@yahoogroups.com
> 
> To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 
> 
> 
> 
> 
> 
> 
> [Non-text portions of this message have been removed]