68300

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

John,

clearly you know what you are doing so there is little chance I
could be much help, but let me try something you did not explicitly
mention.
 All the timing numbers you give suggest everything is working fine
on the 68K part of the system. My experience shows that whenever
there is a wintel part involved, it is a source of problems one
must tackle (this is why I avoid them like the plague...).
What if your DELL system fouls up every once per 1024
or whatever counter there is and sends a too long burst, or something
of that sort?
 Again, this is a very long shot, mostly triggered by my "love" to
wintel systems, but then I believe the hit chances are non-zero.

Dimiter

--------------------------------------------------------------------
Dimiter Popoff
Transgalactic Instruments, Gourko Str. 25 b, 1000 Sofia, Bulgaria
http://transgalactic.freeyellow.com

> To: 68300@yahoogroups.com
> From: "agawam1964" <agawam1964@...>
> Date: Thu, 23 Oct 2003 12:05:07 -0000
> 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
>

Dimiter -

Thanks for replying so quickly.

I share you concern with wintel systems but I figure a CAN bus and 
10ft of cable gives me enough separation.

My first thought was that the Rx ISR was getting overwhelmed but at 
125K baud each CAN packet is between 750 and 1000 usec wide, so the 
500 usec ISR is able to keep up.  I verified this with the oscope and 
pin toggling - we set up a test case where we bombard the TouCAN with 
1000 messages just as fast as we could send them at 125K - and the Rx 
ISR does fine.

However, that is without an Tx messages going out.  When we add a Tx 
transmission into the mix is when we have problems - but not every 
Tx - just one in a few thousand. I'm convinced that somehow the Tx 
routine is timed right so it touches something in a register the Rx 
needs, just before or during (!?!) the Rx ISR.  What that is is the 
problem.



--- In 68300@yahoogroups.com, Dimiter Popoff <tgi_earth@m...> wrote:
> John,
> 
> clearly you know what you are doing so there is little chance I
> could be much help, but let me try something you did not explicitly
> mention.
>  All the timing numbers you give suggest everything is working fine
> on the 68K part of the system. My experience shows that whenever
> there is a wintel part involved, it is a source of problems one
> must tackle (this is why I avoid them like the plague...).
> What if your DELL system fouls up every once per 1024
> or whatever counter there is and sends a too long burst, or 
something
> of that sort?
>  Again, this is a very long shot, mostly triggered by my "love" to
> wintel systems, but then I believe the hit chances are non-zero.
> 
> Dimiter
> 
> --------------------------------------------------------------------
> Dimiter Popoff
> Transgalactic Instruments, Gourko Str. 25 b, 1000 Sofia, Bulgaria
> http://transgalactic.freeyellow.com
> 
> 
> 
> > To: 68300@yahoogroups.com
> > From: "agawam1964" <agawam1964@y...>
> > Date: Thu, 23 Oct 2003 12:05:07 -0000
> > 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
> >

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@...>
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]

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]

John,

I do have a trick for "seeding" the Tx IFLAG bit, and yes, it's during 
initialization.

Put the TouCAN into loopback mode and transmit a dummy, zero-data-byte 
frame.  My init routine waits for the transmission to complete and 
switches out of loopback mode.  My Tx interrupt handler doesn't have to 
worry about getting out of loopback mode.

However, you can poll the Tx buffer's CODE field assuming you intialize it 
correctly.  After a full Tx buffer (code=1100) transmits its frame, the 
new code is 1000.  Poll for binary 1000 and it should work.

The filters in the TouCAN are not as friendly as you'd like.  No Rx buffer 
can act as a backup for another.  When the TouCAN looks for a suitable Rx 
buffer, the full/empty status is ignored (unfortunately).  So in your 
setup, MB 2 will never receive a message even if MB 1 is full.

Also, the TouCAN receives its own transmissions (if filters permit).  Does 
your filter for MB 1 allow your own transmission into MB 1?  That could 
cause back-to-back messages destined for MB 1.  If your Rx ISR isn't fast 
enough, you'd get overflow.

Jeff





"agawam1964" <agawam1964@...>
10/24/2003 08:25 AM
Please respond to 68300

 
        To:     68300@yahoogroups.com
        cc: 

        Subject:        [68300] Re: TouCAN Dropping Messages



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]



---------------------------------------------------
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]