16.9.18.3 Behavior/Usage of MTOF0/1 Bit in User Applications
The MTOF0/1 bit is automatically cleared by the CPK (along with the TOS
n
bit) upon transmission/reception
by the mailbox, which asserted this flag in the first place. It can also be cleared by the user (via the CPU). On
a time-out condition, the MTOF0/1 bit (and the TOS.
n
bit) is set. On an (eventual) successful communication,
these bits are automatically cleared by the CPK. Following are the possible behaviors/usage for the MTOF0/1
bit:
1. Time-out condition occurs. Both MTOF.
n
bit and TOS.
n
bits are set. Communication is never successful; that
is, the frame was never transmitted (or received). An interrupt is asserted. Application should handle this
issue as desired and clear TOC.
n
bit which clears TOS.
n
bit which in turn clears the MTOF.
n
bit.
2. Time-out condition occurs. Both MTOF.
n
bit and TOS.
n
bits are set. However, communication is eventually
successful; that is, the frame gets transmitted (or received). Both MTOF.
n
bit and TOS.
n
bits are cleared
automatically by the CPK. An interrupt is still asserted because the interrupt occurrence was recorded in the
PIE module. When the ISR scans the GIF register, it doesn't see the MTOF0/1 bit set. This is the phantom
interrupt scenario. This is handled per the application requirements.
3. Time-out condition occurs. Both MTOF0/1 bit and TOS.
n
bits are set. While executing the ISR pertaining
to time-out, communication is successful. This situation must be handled carefully. The application should
not re-transmit a mailbox if the mailbox is sent between the time the interrupt is asserted and the time the
ISR is attempting to take corrective action. One way of doing this is to poll the TM/RM bits in the CANES
register. These bits indicate if the CPK is currently transmitting/receiving. If that is the case, the application
should wait till the communication is over and then check the TOS.
n
bit again. If the communication is still
not successful, then the application should take the corrective action.
16.9.19 Mailbox Layout
The following four 32-bit registers comprise each mailbox:
• MSGID − Stores the message ID
• MSGCTRL − Defines number of bytes, transmission priority and remote frames
• CANMDL − 4 bytes of data
• CANMDH − 4 bytes of data
16.9.19.1 Message Identifier Register (MSGID)
This register contains the message ID and other control bits for a given mailbox.
Note
This register can be written only when mailbox n is disabled (CANME[n] (CANME.31-0) = 0). The
reset-state of IDE, AME, and AAM bits are undefined. As part of module initialization, these bits
must be initialized as appropriate. Otherwise, they may assume random values and lead to improper
operation of the mailboxes.
Figure 16-37. Message Identifier Register (MSGID) Register
31
30
29
28
0
IDE
AME
AAM
ID[28:0]
R/W-x
R/W-x
R/W-x
R/W-x
LEGEND: R/W = Read/Write; R = Read only; -
n
= value after reset; x = indeterminate
Controller Area Network (CAN)
1050
TMS320x2806x Microcontrollers
SPRUH18I – JANUARY 2011 – REVISED JUNE 2022
Copyright © 2022 Texas Instruments Incorporated
Содержание TMS320 2806 Series
Страница 2: ......