XA-C3 Datasheet, PDF (51/68 Pages) NXP Semiconductors – XA 16-bit microcontroller family 32K/1024 OTP CAN transport layer controller 1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID Filters, transport layer co-proce

Philips Semiconductors
XA 16-bit microcontroller family
32K/1024 OTP CAN transport layer controller
1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID filters, transport layer co-processor
Preliminary specification
XA-C3
DMA, and then interrupt the CPU that a complete message has
been received.
Since Data Byte 1 of each frame contains the Fragmentation
information, it will never be stored in the CTL message buffer, thus
each frame will have up to seven bytes of data stored. After the
entire message is received, the message buffer will contain all of the
actual informational data bytes received (exclusive of Fragmentation
information bytes) plus the Byte Count at location 00 which will
contain the total number of informational data bytes stored.
Fragmentation Error
By looking at the Fragmentation information, the message handler
can determine the first frame , the middle frames, the end frame of
the message, and each sequence number. In the case of CANopen,
there is no sequence number but rather a one bit field that toggles
each frame. If a Fragmentation error occurs, the message handler
will reset the byte count, address pointer, and generate an interrupt
to the CPU. At this point the CTL message buffer is determined to
be invalid.
Fragmentation checking is disabled for all objects when CAN is the
system protocol (Prtcl[1:0] = 00).
Fragmentation error occurs only one way:
1. When the message handler receives a frame where the
sequence number is NOT one greater than that of the previous
frame. Or in the case of CANopen, the toggle bit has not toggled.
Fragmented Messages in OSEK
There are several important items that must be kept in mind with
regard to hardware assembly of Fragmented OSEK messages. For
a complete discussion, please see the XA-C3 User Manual. These
items are summarized below:
D The OSEK FirstFrame cannot be treated as part of the
Fragmented message, but must be handled as a completely
separate, single–frame, non–Fragmented message. However, the
FirstFrame may contain the first several bytes of User–data.
D For the object receiving the forthcoming message Fragments, the
MnFCR register must be initialized by the User to point at an
address other than the buffer base location. This can be byte
offset ‘1’ or some other, more strategically chosen location. Since
there will be no FirstFrame received for this object, there will be
no write of 00h to the buffer base location, by DMA, at the
beginning of the message.
D The Fragment Count Register (MnFCR) of the object receiving the
message Fragments must be initialized by the User before
enabling the object for receive. The initial value written to MnFCR
must be identical to the SequenceNumber of the first
ConsecutiveFrame that arrives (typically 0h).
D There is no “Last Frame” encoding for OSEK. Therefore, there will
be neither an Rx Message Complete Status Flag, nor an interrupt,
nor a Byte Count write associated with Rx Message Complete, at
the conclusion of a Fragmented message. However, by carefully
choosing the initial value for the MnBLR register, the User can
arrange to get an Rx Buffer Full interrupt, and the associated Rx
Buffer Full Byte Count write, instead.
Fragmented Messages in CANopen
In a CANopen system, the software will need to write to the object‘s
Fragment Count Register (MnFCR) to initialize the toggle bit prior to
receiving the first frame of any new message which requires
hardware Fragmentation assembly. This bit will have to be initialized
to the same state that will be received in the 1^st packet (typically 0).
This bit will need to be initialized each time a new channel is
established, even if none of the other parameters change (e.g.,
Match, Mask, buffer location, buffer size, etc.).
Since the hardware cannot detect a message start, there can be no
semaphore write to the bottom of the buffer space at the start of a
new Fragmented message (for a discussion of the semaphore, see
the section entitled Using the Semaphore Bits, SEM1 and SEM0 on
page 46. This location must still be left free for the hardware to write
the byte count into at the end of the message. This means that for
CANopen Fragmented messages (only Fragmented) the software
must initialize the address pointer to location ‘1’ of the
designated receive buffer, not location ‘0’ as it does in
DeviceNet. It also implies, of course, that the software loses the
ability to check the semaphore to determine if message
reconstruction is currently in progress.
Essentially, the hardware will treat the first frame of a multi–frame
CANopen message exactly the same as intermediate frames.
Auto–Acknowledge in CANopen
A Fragmented (Segmented) CANopen message may need to be
acknowledged on a frame by frame basis. The XA-C3 provides
hardware support for this process, with no CPU intervention. Of
course the User may elect not to auto–acknowledge, or to
implement the acknowledge function in software.
Suppose Message Object n ( n = 0…31) is enabled for receive, with
the FRAG bit set. If the high level protocol is CANopen, as selected
in the GCTL register, then the following steps must be taken to
ensure that CANopen frames are automatically acknowledged:
D Set the AUTO_ACK bit in GCTL.
D Set up a transmit object sequential to the CANopen receive
object, i.e., the object number set to be n+1. Set the FRAG bit for
this object.
D It is important NOT to set the OBJ_EN bit for the transmit
message.
With the above setup, the XA-C3 will automatically generate a
transmit frame upon successful reception of a CANopen frame. The
User must setup the screener ID for the Tx frame in the M_n+1MIDH
and M_n+1MIDL registers, the RTR bit in M_n+1CNTL[0], and the DLC
in M_n+1MSKH[3:0]. The User must also store the proper
“Acknowledge Byte”, as defined by the protocol specification, in byte
offset 0 of the Tx object’s message buffer. Bit position [4] is a don’t
care, because the XA-C3 will automatically insert the toggle bit value
from the incoming frame into the toggle bit position of the outgoing
auto–acknowledge frame. The format for storing the Acknowledge
Byte is shown below in Table 24 (subject to change without notice
by the CiA).
2000 Jan 25
44