If the ECLK is used as an external bus control signal (ESTR=1) the first

external access is lost after switching from a single chip mode with

enabled ECLK output to an expanded mode. The ECLK is erroneously held in

the high phase thus the first external bus access does not generate a

rising ECLK edge for the external logic to latch the address. The ECLK

stretches low after the lost access resulting in all following external

accesses to be valid. 

Enter expanded mode with ECLK output disabled (NECLK=1). Enable the ECLK

after switching the mode before executing the first external access. 

When messages received by the msCAN controller are not serviced in 

time, such that the five-stage FIFO becomes full, one data byte of 

the oldest message in the receive buffer FIFO may contain invalid data

with the value 0x7F.



The data lengths of the oldest and the newest message in the FIFO 

determine if this occurs, and if so, the position of the affected Data

Segment Register (DSR) byte:

 

      DSR(n+2) is affected in oldest message if newest message has data

length n.





CONDITIONS UNDER WHICH THE ERROR OCCURS



This issue occurs only when the message buffer FIFO runs full:

   The FIFO has been filled with four messages 'a' (oldest), 'b', 'c', 

   and 'd', when a new message 'e' is received that is protocol 

   compliant (no errors) and that passes the acceptance filter.



and the oldest and newest message lengths meet the following critera:

   The data length codes, La and Le, of messages 'a' and 'e' are such 

   that:

      3  <= La <= 8, and

      0  <= Le <= 5, and

      Le <= La - 3.



Example



Consider the case where La = 8, and Le = 4.

Here n = Le = 4, therefore byte DSR(n+2) = DSR6 (i.e. the seventh data

byte of message 'a') gets written to 0x7F.



PROBABILITY OF THE ERROR OCCURRING



A. The FIFO runs full without service (near-overrun situation) - Pa:

   Application software will typically avoid this possible overrun 

   situation, minimizing the probability of this condition occurring - 

   hence this is typically a very low probability (that is dependent on     

   the application implementation).



B. Message length dependency - Pb:

   If all Rx messages have the same length, or are 6, 7, or 8 bytes  

   long, there is no possibility of the error occurring, and Pb = 0.



   For random non-0 data lengths, Pb = 0.25 (approximately).



Overall, the probability of the error occurring is P = Pa x Pb. 

The following precautions can be taken to avoid the problem:



- Do not allow the receive FIFO buffer to become full. 

  > If necessary, raise the Rx interrupt priority so that condition

    A is avoided.

- Use constant data lengths (any value) for the Rx messages

  > E.g. use eight bytes only, and pad shorter messages with dummy

    bytes

- Use (mixed) data lengths in the range 6 to 8.

- Use (mixed) data lengths in the range 1 to 3.

- Use a parity or checksum scheme to detect a corrupted byte.

- Check for the 'critical' value 0x7F in bytes 3 to 8. 

When an OC7M bit is set, an erroneous normal output compare event can 

happen on a timer port if the compare action is selected as "Timer 

disconnected from output pin logic ".

 

Corresponding configuration:

*  TIOSx = 1 --> Output compare mode

*  OMx = OLx = 0 --> Output compare logic disconnected from the pin

*  OC7Mx = 1 --> Mask bit set for OC7 event











 

Set OC7Mx = 1 only for channels where the output compare action should 

drive the pin, and OC7Mx = 0 for all other channels where the pin is 

required to be disconnected from the output compare logic. 

With the SPI configured as a slave, clearing the SPE bit (to disable 

the SPI) together with clearing the CPHA bit while the SS pin is low 

causes the transmit shift register to be locked for the next 

transmission following the SPI being re-enabled as a slave with SS 

still being low. 



This means new transmit data is not accepted for the first 

transmission after re-enabling the SPI (indicated by SPTEF staying low 

after storing transmit data into SPIDR), but for the next following 

transmission.



 

When disabling the slave SPI, CPHA should not be cleared at the same time. 

This erratum is only relevant for applications using more than one 

transmit buffer and with oscillators operating at opposite ends of the 

tolerance range.



A corrupt ID will be sent out if a Tx message with highest priority is 

set up for transmission during bit 3 of INTERMISSION and a dominant 

bit is sampled leading to an early-SOF* condition. 



The message sent will be taken from the newly setup Tx buffer with the 

exception of the first eight ID bits which are taken from the 

originally selected Tx buffer. 



The CRC is correctly calculated on the resulting bit stream so that 

receiving nodes will validate the message.



In a typical CAN network, with oscillator tolerances inside of 

the specified limits, this will not be an issue because an early-SOF

condition should not occur. This may only be a problem if the 

oscillators operate at opposite ends of the tolerance range (max. 

1.58%) which could lead to a cumulated phase error after 10 bit times 

larger than phase segment 2.



*The CAN protocol condition referred to as 'early-SOF' in this erratum 

is detailed in a Note in the "Bosch CAN Specification Version 2.0 Part 

B", section 3.2.5 INTERFRAME SPACING - INTERMISSION.







 

There is no generic detection of the error condition available.



System-level workarounds may be feasible:



- Use only one transmit buffer and do priority sorting in software



If more than one transmit buffer must be used, one of the following

workarounds can be chosen:



- Do not release higher priority messages than those already

  scheduled (either determined by local priority or if equal, by 

  hard-coded buffer priority) before all buffers are empty

- Abort messages before scheduling higher priority transmissions

- Prevent bad IDs passing acceptance filters by not assigning IDs (x) 

  consisting of a combination of other assiged IDs (y,z), 

  i.e.  IDx[11:0] != {IDy[11:3], IDz[2:0]}  for standard 

  and  IDx[28:21] != {IDy[28:21],IDz[20:0]} for extended identifiers

- Allocate dedicated data length codes (DLC) to every ID and check 

  for correspondence after reception





 

It is possible that after the device enters Stop or Pseudo-Stop mode it

may reset rather than wake up normally upon reception of the wake-up

signal. 



CONDITIONS:

This will only happen provided ALL of the following conditions are met: 

    1) Device is powered by the on-chip voltage regulator.

    2) Device enters stop or pseudo-stop mode by execution of STOP

instruction by the CPU (providing the S-bit in CCR is cleared) 

NOTE: The part enters stop mode either after 12 oscillator clock cycles

with the PLL disengaged or 3 PLL clock cycles and 8 oscillator clock

cycles with the PLL engaged after the STOP command is executed. 

    3) The wake-up signal is activated within a specific very short

window (typically 11ns long, not longer than 20ns). The position of the

window varies between different devices, however it never starts sooner

than 1.6µs and never ends later than 4.7µs after the stop mode entry. 

This really narrow width of the susceptible window (20ns maximum) makes

the erratum unlikely to ever show in the applications life. 



The incorrect behavior will never occur if ANY of the wake-up conditions

are met at the time when the stop mode entry is attempted (an enabled

interrupt is pending). 



EFFECT:

If this incorrect behavior occurs, the device will Reset and indicate a

Low Voltage Reset (LVR) as the reset source. 

The device will operate normally after the reset. 

None.



--



Asynchronous Low Voltage Resets are possible in any microcontroller

application (due to power supply drops) and the integrated LVR and LVI

features and dedicated LVR reset vector are provided to manage this fact

cleanly. For best practice, the application's software should be written

to recover from a Low Voltage Reset in a controlled manner. 

An application software written to deal with valid Low Voltage Resets

should correctly manage erroneous LVR events. 



It can also be possible to avoid erroneous Low Voltage Resets from

synchronous wake-up events by configuring the application software to

ensure that the entry into stop occurs at such a time, in relation to

the wake-up event timer, that a wake-up event does not occur within

1.6µs to 4.7µs after Stop/Pseudo-Stop entry. 

When the ATD is started with write to ATDCTL5

and, which is very unusual and not necessary,

within a certain period again started with write

to ATDCTL5. The conversion will not start at all.

This does only happen if the two consecutive writes to ATDCTL5 occur 

within one "ATD clock period". An ATD clock period is defined by a full 

rollover of the ATD clock prescaler. That is for example PRS[4:0] = 2 -

> (2+1)*2 = within 6 bus cycles.

 

Only write once to ATDCTL5 when starting a conversion.



Use the recommended start and abort procedures from the Block Guide.

Section : Initialization/Application Information Subsection: Setting up

and starting an A/D conversion Subsection: Aborting an A/D conversion