Forums

56803 erratum 11.8: missed MSCAN TXEIE

Started by Corey, Rick April 14, 2003
Hi

I only just recently noticed the MSCAN erratum 11.8 (copied below). I was
puzzled by this.

I thought that as long as the flag bit was set (TXE[2:0] in the CANTFLG
register), the Transmitter Empty IRQ was valid, or asserted, or would cause
an ISR to fire (whenever the TXEIE was enabled). In my past understanding,
I would have thought that "missing" the initial TXE event would not matter
greatly, because as long as I did not re-fill the TX buffer, it would keep
asserting the IRQ until I did fill the Tx buffer (even if I re-enabled TXEIE
five minutes later). I suppose I thought that MSCAN polled its Tx buffers
periodically and asserted the "TXE flag" and TXEIE interrupt insistently.

Is this erratum saying that in rare combinations of circumstances involving
disabling and re-enabling TXEIE during active CAN transmission, a Tx buffer
can go empty, and stay empty, and never set TXE, and never cause the TXE
IRQ, even several clock cycles later?

It seems that, if one were relying on TXEIE to prompt one to reload the TX
buffer, this erratum would stall CAN communication altogether (if one were
using only one of the three TX buffers). I've never noticed that happening
- perhaps it is just rare enough that I haven't seen it yet.

If so, it sounds to me now more as if the transition of *going empty* is
what sets TXE, and the "insistence" of the TXEIE IRQ is due to the
persistent flag in TXE, not the empty state of the TX buffer. And yet, if I
(naughtily) clear the TXE flag with a TX buffer still empty, the TXEIE IRQ
is asserted again very promptly. I'm puzzled about the internal algorithm
that seems always to "know" when a TX buffer is empty, yet can still cause
the erratum described below.

I understand that the intended usage of MSCAN is to disable the TXEIE IRQ
only once there is no more data to send. (The erratum suggests disabling
the TXEIE using ITCN-PLR#14 instead of the MSCAN Transmit Control Register
CANTCR TXEIE bits - whatever is necessary.)

However, since I have been disabling CAN TX IRQs while I add messages to an
application-level Tx queue, I had better use the ITCN method instead of the
CANTCR-TXEIE method, since I must disable CAN IRQs during active
transmission.

Rick Corey Missed MSCAN transmitter empty interrupt

Impact:
When disabling and enabling the MSCAN transmitter empty interrupt enable
(TXEIE) bits in the transmitter control register (CANTCR) while transmitting
the
peripheral will sometimes miss the transmitter empty event. The missed event
means that the ITCN peripheral will not be notified and the interrupt
service routine
for the transmitter empty interrupt will not be invoked. The sequence below
is
required to see the problem:

1. Start a CAN message transmitting and set bit TXEIE bit in CANTCR to
enable
the MSCAN transmit interrupt.

2. Before the CAN message transmission completes clear TXEIE bit in CANTCR
to disable the MSCAN transmit interrupt.

3. In a very small time window around the completion of the CAN transmission
set
TXEIE bit in CANTCR to enable MSCAN transmit interrupt.
In rare instances the above sequence will cause the MSCAN peripheral to miss
the
transmit empty interrupt.

Work Around:
The most direct work around is to enable the MSCAN transmitter empty
interrupt
in the CANTCR and then not disable and enable the interrupt using the TXEIE
bits
during active CAN transmissions. To disable and enable MSCAN transmit empty
interrupts during active CAN transmission use the ITCN peripheral interrupt
vector #14 PLR bits. To disable the transmit interrupt the PLR14 bits in the
GPR2
register should be set to zero. To enable the interrupt set the PLR14 bits
to a
priority of 1 or above. Using the ITCN to perform the interrupt
enabling/disabling
function corrects all the issues and never misses any transmit empty
interrupts.

Rick Corey
Senior Software Engineer
DPC Instrument Systems Division



Rick -

We were doing a review of all the posts and noticed this had not been answered,
so sorry for the long delay. The way this errata will manifest itself will be to
miss a transmitt interrupt and does in fact typically stall the CAN
communications. The window of oppurtunity is quite narrow so it is quite
infrequent and depending on the timing of your software it might never occur.

The work around though is bullit proof and interupts are never missed. Thanks.

- Bill

-----Original Message-----
From: Corey, Rick [mailto:]
Sent: Monday, April 14, 2003 7:16 AM
To: ; ;
; ;

Subject: [motoroladsp] 56803 erratum 11.8: missed MSCAN TXEIE Hi

I only just recently noticed the MSCAN erratum 11.8 (copied below). I was
puzzled by this.

I thought that as long as the flag bit was set (TXE[2:0] in the CANTFLG
register), the Transmitter Empty IRQ was valid, or asserted, or would cause
an ISR to fire (whenever the TXEIE was enabled). In my past understanding,
I would have thought that "missing" the initial TXE event would not matter
greatly, because as long as I did not re-fill the TX buffer, it would keep
asserting the IRQ until I did fill the Tx buffer (even if I re-enabled TXEIE
five minutes later). I suppose I thought that MSCAN polled its Tx buffers
periodically and asserted the "TXE flag" and TXEIE interrupt insistently.

Is this erratum saying that in rare combinations of circumstances involving
disabling and re-enabling TXEIE during active CAN transmission, a Tx buffer
can go empty, and stay empty, and never set TXE, and never cause the TXE
IRQ, even several clock cycles later?

It seems that, if one were relying on TXEIE to prompt one to reload the TX
buffer, this erratum would stall CAN communication altogether (if one were
using only one of the three TX buffers). I've never noticed that happening
- perhaps it is just rare enough that I haven't seen it yet.

If so, it sounds to me now more as if the transition of *going empty* is
what sets TXE, and the "insistence" of the TXEIE IRQ is due to the
persistent flag in TXE, not the empty state of the TX buffer. And yet, if I
(naughtily) clear the TXE flag with a TX buffer still empty, the TXEIE IRQ
is asserted again very promptly. I'm puzzled about the internal algorithm
that seems always to "know" when a TX buffer is empty, yet can still cause
the erratum described below.

I understand that the intended usage of MSCAN is to disable the TXEIE IRQ
only once there is no more data to send. (The erratum suggests disabling
the TXEIE using ITCN-PLR#14 instead of the MSCAN Transmit Control Register
CANTCR TXEIE bits - whatever is necessary.)

However, since I have been disabling CAN TX IRQs while I add messages to an
application-level Tx queue, I had better use the ITCN method instead of the
CANTCR-TXEIE method, since I must disable CAN IRQs during active
transmission.

Rick Corey Missed MSCAN transmitter empty interrupt

Impact:
When disabling and enabling the MSCAN transmitter empty interrupt enable
(TXEIE) bits in the transmitter control register (CANTCR) while transmitting
the
peripheral will sometimes miss the transmitter empty event. The missed event
means that the ITCN peripheral will not be notified and the interrupt
service routine
for the transmitter empty interrupt will not be invoked. The sequence below
is
required to see the problem:

1. Start a CAN message transmitting and set bit TXEIE bit in CANTCR to
enable
the MSCAN transmit interrupt.

2. Before the CAN message transmission completes clear TXEIE bit in CANTCR
to disable the MSCAN transmit interrupt.

3. In a very small time window around the completion of the CAN transmission
set
TXEIE bit in CANTCR to enable MSCAN transmit interrupt.
In rare instances the above sequence will cause the MSCAN peripheral to miss
the
transmit empty interrupt.

Work Around:
The most direct work around is to enable the MSCAN transmitter empty
interrupt
in the CANTCR and then not disable and enable the interrupt using the TXEIE
bits
during active CAN transmissions. To disable and enable MSCAN transmit empty
interrupts during active CAN transmission use the ITCN peripheral interrupt
vector #14 PLR bits. To disable the transmit interrupt the PLR14 bits in the
GPR2
register should be set to zero. To enable the interrupt set the PLR14 bits
to a
priority of 1 or above. Using the ITCN to perform the interrupt
enabling/disabling
function corrects all the issues and never misses any transmit empty
interrupts.

Rick Corey
Senior Software Engineer
DPC Instrument Systems Division <http://rd.yahoo.com/M$5454.3115308.4434529.1728375/D=egroupweb/S05771855:H\
M/A57554/R=0/*http://ipunda.com/clk/beibunmaisuiyuiwabei>

<http://us.adserver.yahoo.com/l?M$5454.3115308.4434529.1728375/D=egroupmail/S=\
:HM/A57554/rand32594114>

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