Filter
Top Products
121 www.national.com
CP3BT26
All contents of the hidden receive buffer are always copied
into the respective receive buffer. This includes the received
message ID as well as the received Data Length Code
(DLC); therefore when some mask bits are set to don’t care,
the ID field will get the received message ID which could be
different from the previous ID. The DLC of the receiving buff-
er will be updated by the DLC of the received frame. The
DLC of the received message is not compared with the DLC
already present in the CNSTAT register of the message buff-
er. This implies that the DLC code of the CNSTAT register
indicates how may data bytes actually belong to the latest
received message.
The remote frames are handled by the CAN interface in two
different ways. In the first method, remote frames can be re-
ceived like data frames by configuring the buffer to be
RX_READY and setting the ID bits including the RTR bit. In
that case, the same procedure applies as described for
Data Frames. In the second method, a remote frame can
trigger one or more message buffer to transmit a data frame
upon reception. This procedure is described under To An-
swer Remote Frames on page 123.
19.5.1 Receive Timing
As soon as the CAN module receives a “dominant” bit on
the CAN bus, the receive process is started. The received
ID and data will be stored in the hidden receive buffer if the
global or basic acceptance filtering matches. After the re-
ception of the data, CAN module tries to match the buffer ID
of buffer 0...14. The data will be copied into the buffer after
the reception of the 6th EOF bit as a message is valid at this
time. The copy process of every frame, regardless of the
length, takes at least 17 CKI cycles (see also CPU Access
to CAN Registers/Memory on page 127). Figure 53 shows
the receive timing.
Figure 53. Receive Timing
To indicate that a frame is waiting in the hidden buffer, the
BUSY bit (ST[0]) of the selected buffer is set during the copy
procedure. The BUSY bit will be cleared by the CAN module
immediately after the data bytes are copied into the buffer.
After the copy process is finished, the CAN module changes
the status field to RX_FULL. In turn, the CPU should
change the status field to RX_READY when the data is pro-
cessed. When a new object has been received by the same
buffer, before the CPU changed the status to RX_READY,
the CAN module will change the status to RX_OVERRUN to
indicate that at least one frame has been overwritten by a
new one. Table 46 summarizes the current status and the
resulting update from the CAN module.
During the assertion of the BUSY bit, all writes to the receiv-
ing buffer are disabled with the exception of the status field.
If the status is changed while the BUSY bit is asserted, the
status is updated by the CAN module as shown in Table 46.
The buffer states are indicated and controlled by the ST[3:0]
bits in the CNSTAT register (see Buffer Status/Control Reg-
ister (CNSTAT) on page 128). The various receive buffer
states are explained in RX Buffer States on page 122.
19.5.2 Receive Procedure
Software executes the following procedure to initialize a
message buffer for the reception of a CAN message.
1. Configure the receive masks (GMASK or BMASK).
2. Configure the buffer ID.
3. Configure the message buffer status as RX_READY.
To read the out of a received message, the CPU must exe-
cute the following steps (see Figure 54):
Copy to Buffer
SOF
1 BIT
IFS
3 BIT
EOF
7 BIT
BUSY
rx_start
BUS
ACK
FIELD
2 BIT
CRC
FIELD
16 BIT
DATA FIELD
(IF PRESENT)
n × 8 BIT
ARBITRATION FIELD
+
CONTROL
12/29 BIT
+
6 BIT
BUS
IDLE
DS037
Table 46 Writing to Buffer Status Code During
RX_BUSY
Current Status Resulting Status
RX_READY RX_FULL
RX_NOT_ACTIVE RX_NOT_ACTIVE
RX_FULL RX_OVERRUN