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

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