Document Number: 002-10635 Rev. *I
Page
264 of 325
S6J3310/20/30/40 Series
•
In case the ID won arbitration, a CAN message with valid CRC is transmitted.
•
In case this message is acknowledged, the ID stored in the Tx Event FIFO is the ID of the requested Tx
message and not the ID of the message transmitted on the CAN bus
•
Neither an error is detected by the transmitting node nor at the receiving node.
■ Workaround
Workaround 1:
This workaround avoids submitting a transmission request in the critical time window of about one bit time before the sample
point of the 3
rd
bit of intermission field when on other pending transmission request exists:
•
Request a new transmission if another transmission is already pending or when the M_CAN / M_TTCAN is not in
state "Receiver" (when PSR.ACT ≠ "10").
•
If no pending transmission request exists, the application software needs to evaluate the Rx Interrupt flags
IR.DRX, IR.RF0N, IR.RF1N which are set at the last bit of EoF when a received and accepted message gets
valid.
•
A new transmission may be requested by writing to TXBAR once the Rx interrupt occurred and the application
waited another 3 bit times before submitting its Tx request. Note the Rx interrupt is generated at the last bit of
EoF which is followed by three bits of Intermission.
•
The application has to take care that the transmission request for the CAN Protocol Controller is activated before
the critical window of the following reception is reached.
A supplemental action can be applied in order to detect messages which contain wrong ID and control filed information:
•
A checksum covering arbitration and control fields can be added to the data field of the message to be
transmitted, to detect frames transmitted with wrong arbitration and control fields.
Workaround 2:
This workaround ensures that always at least one pending Tx request exists. If that is the case, the application may launch
its Tx requests at any time without suffering from the limitation.
•
Define a low priority message with DLC = 0 that can be sent without harm. E.g. loses arbitration against all other
application messages, does not pass any acceptance filter of nodes in the same network. DLC = 0 shall reduce
latency for other application messages.
•
Configure sufficient Tx buffers – at least two - for this message type thus that there is always another one waiting
to be sent. E.g. an application that cannot react quickly enough with the time a single message of this type is
sent, more than 2 Tx buffer may become necessary.
•
The application uses the standard interfaces of the CAN / CAN FD stack to feed these messages.
•
Whenever Tx confirmation is indicated for the second but last message of this type with pending Tx request, the
application needs to submit at least one new Tx request. Note Tx confirmation is a standard feature in the
AUTOSAR SW architecture.
•
Before initially l
eaving INIT state of the M_CAN IP by clearing CCCR.INIT bit, make sure to activate a Tx request
after having cleared CCCR.CCE. This will ensure that the conditions for the occurrence of the limitation when
synchronizing to the CAN bus the first time after RESET are prevented.
■ Fix Status
Not be planned.
