Filter
Top Products
720
Chapter 34 CAN Controller
3.Functional Description
3. Functional Description
This chapter provides an overview of the CAN module’s operating modes and how to use them.
3.1 Software Initialisation
The software initialization is started by setting the bit Init in the CAN Control Register, either by software or by
a hardware reset, or by going Bus_Off.
While Init is set, all message transfers from and to the CAN bus are stopped, the status of the CAN bus output
CAN_TX is recessive (HIGH). The counters of the EML are unchanged. Setting Init does not change any
configuration register.
To initialize the CAN Controller, the CPU has to set up the Bit Timing Register and each Message Object. If a
Message Object is not needed, it is sufficient to set its MsgVal bit to not valid. Otherwise, the whole Message
Object has to be initialized.
Access to the Bit Timing Register and to the BRP Extension Register for the configuration of the bit timing is
enabled when both bits Init and CCE in the CAN Control Register are set.
Resetting Init (by CPU only) finishes the software initialisation. Afterwards the Bit Stream Processor BSP
synchronizes itself to the data transfer on the CAN bus by waiting for the occurrence of a sequence of 11
consecutive recessive bits (= Bus Idle) before it can take part in bus activities and starts the message transfer.
The initialization of the Message Objects is independent of Init and can be done on the fly, but the Message
Objects should all be configured to particular identifiers or set to not valid before the BSP starts the message
transfer.
To change the configuration of a Message Object during normal operation, the CPU has to start by setting
MsgVal to not valid. When the configuration is completed, MsgVal is set to valid again.
3.2 CAN Message Transfer
Once the CAN is initialized and Init is reset to zero, the CAN’s CAN Core synchronizes itself to the CAN bus
and starts the message transfer.
Received messages are stored in their appropriate Message Objects if they pass the Message Handler’s
acceptance filtering. The whole message including all arbitration bits, DLC and eight data bytes is stored in the
Message Object. If the Identifier Mask is used, the arbitration bits which are masked to “don’t care” may be
overwritten in the Message Object.
The CPU may read or write each message any time via the Interface Registers, the Message Handler
guarantees data consistency in case of concurrent accesses.
Messages to be transmitted are updated by the CPU. If a permanent Message Object (arbitration and control
bits set up during configuration) exists for the message, only the data bytes are updated and then TxRqst bit
with NewDat bit are set to start the transmission. If several transmit messages are assigned to the same
Message Object (when the number of Message Objects is not sufficient), the whole Message Object has to be
configured before the transmission of this message is requested.
The transmission of any number of Message Objects may be requested at the same time, they are transmitted
subsequently according to their internal priority. Messages may be updated or set to not valid any time, even
when their requested transmission is still pending. The old data will be discarded when a message is updated
before its pending transmission has started. Depending on the configuration of the Message Object, the
transmission of a message may be requested autonomously by the reception of a remote frame with a
matching identifier.
3.3 Disabled Automatic Retransmission
According to the CAN Specification (see ISO11898, 6.3.3 Recovery Management), the CAN provides means
for automatic retransmission of frames that have lost arbitration or that have been disturbed by errors during
transmission. The frame transmission service will not be confirmed to the user before the transmission is
successfully completed. By default, this means for automatic retransmission is enabled. It can be disabled to
enable the CAN to work within a Time Triggered CAN (TTCAN, see ISO11898-1) environment. The Disabled