
ML9620 User’s Manual
Chapter 3
Operational Description
3 - 1
Chapter 3
Operational Description
3.1
Operational Procedure
3.1.1 Software Initialization
Setting Init bit in the CAN Control Register allows initialization by the software to be executed.
The bit is set by
the software or by the hardware reset, or when the state of CAN bus has become Busoff.
While Init bit is set, all message transfer from and to the CAN bus is stopped and the status of the CAN bus output
TX is recessive (HIGH).
The error counters are unchanged.
Setting Init does not change any configuration
register.
To initialize the CAN Controller, the MCU has to set up the Bit Timing Register and each Message Object.
If a
Message Object is not needed, it is sufficient to set it’s 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 MCU only) finishes the software initialisation. Afterwards the CAN bus by waiting for the
occurrence of a sequence of 11 consecutive recessivebits (= 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 message transfer.
To change the configuration of a Message Object during normal operation, the MCU has to start by setting
MsgVal to not valid. When the configuration is completed, MsgVal is set to valid again.
3.1.2 CAN Message Transfer
Once the ML9620 is initialized and Init is reset to ‘0’, the ML9620’s CAN Control synchronizes itself to the CAN
bus and starts the message transfer.
Received messages are stored into 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 into 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 MCU 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 MCU.
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.