006
Errata Sheet
This Errata Sheet describes the deviations from the current user
documentation.The module oriented classification and numbering system uses
an ascending sequence over several derivatives, including already solved
deviations. So gaps inside this enumeration can occur.
Table 1
Current Documentation
XC886/888CLM Users Manual
V0.1
Jan 2006
XC886/888CLM Data Sheet
V0.1
Feb 2006
Note: Devices marked with EES or ES are engineering samples which may not
be completely tested in all functional and electrical characteristics,
therefore they should be used for evaluation only.
The specific test conditions for EES and ES are documented in a separate
Status Sheet. Errata Sheet
History List / Change Summary
XC888CLM-8FF, ES AB
2/25
Rel. 1.0, 05.06.2006

1
History List / Change Summary
Table 2
History List
Version
Date
Remark
1.0
05.06.2006
Table 3
Errata fixed in this step
Errata
Short Description
Chg
Table 4
Functional Deviations
Functional
Deviation
Short Description
Chg Pg
BROM_XC8.006
IRAM data corrupted after hardware reset
New
5
INT_XC8.004
Unable to Detect New Interrupt Request if
UART1 Interrupt Flags Is Not Cleared
(Unexpectedly)
New
5
INT_XC8.005
Write to IRCON0 Blocks Interrupt Request
of External Interrupt 0,1
New
8
MultiCAN_TC.025 RXUPD behavior
New
9
MultiCAN_TC.026 MultiCAN Timestamp Function
New
9
MultiCAN_TC.027 MultiCAN Tx Filter Data Remote
New
9
MultiCAN_TC.028 STD behavior
New
10
MultiCAN_TC.029 Tx FIFO overflow interrupt not generated
New
11
MultiCAN_TC.030 Wrong transmit order when CAN error at
start of CRC transmission
New
12 Errata Sheet
History List / Change Summary
XC888CLM-8FF, ES AB
3/25
Rel. 1.0, 05.06.2006

MultiCAN_TC.031 List Object Error wrongly triggered
New
13
MultiCAN_TC.032 MSGVAL wrongly cleared in SDT mode
New
14
MultiCAN_TC.035 Different bit timing modes
New
14
OCDS_XC8.008
Watchdog Timer behavior during Debug
with Suspend
New
16
OCDS_XC8.009
Break while CPU is in NMI service mode
New
16
PIN_XC8.005
Glitches on TCK when switching between
clock sources
New
17
Table 5
Deviations from Electrical- and Timing Specification
AC/DC/ADC
Deviation
Short Description
Chg Pg
Table 6
Application Hints
Hint
Short Description
Chg Pg
BROM_XC8.H001
SYSCON0.RMAP handling in ISR
New
19
INT_XC8.H003
Interrupt Flags of External Interrupt 0 and
1
New
19
INT_XC8.H004
NMI Interrupt Request With No NMI Flag
Set
New
21
INT_XC8.H005
Not all Flags are qualified for clearing
Pending Interrupt Request
New
22
MultiCAN_TC.H003 Message may be discarded before
transmission in STT mode
New
24
Table 4
Functional Deviations
Functional
Deviation
Short Description
Chg Pg Errata Sheet
History List / Change Summary
XC888CLM-8FF, ES AB
4/25
Rel. 1.0, 05.06.2006

OCDS_XC8.H002
Any NMI request is lost on Debug entry
and during Debug
New
25
Table 6
Application Hints
Hint
Short Description
Chg Pg Errata Sheet
Functional Deviations
XC888CLM-8FF, ES AB
5/25
Rel. 1.0, 05.06.2006

2
Functional Deviations
BROM_XC8.006 IRAM data corrupted after hardware reset
After the hardware reset, boot up via User Mode (MBC=1) affects certain IRAM
data.
The affected IRAM address range:
(1) 00
H
- 07
H
(2) 80
H
- C7
H
Workaround
None
INT_XC8.004 Unable to Detect New Interrupt Request if UART1 Interrupt
Flags Is Not Cleared (Unexpectedly)
As illustrated in the simplified figure, the UART1 interrupt flags RI and TI are
combined as one interrupt request output. These flags are located within the
UART1 kernel, with a single interrupt request line as output from the kernel. RI
TI
UART1
>=1
interrupt
detection
Errata Sheet
Functional Deviations
XC888CLM-8FF, ES AB
6/25
Rel. 1.0, 05.06.2006

Figure 1
Being of interrupt structure 2, the interrupt request of UART1 is detected on the
rising edge of a positive pulse.
The problem is that it may occur at some point in the application, that any new
UART1 interrupt request can no longer be detected after a return-from-interrupt
(reti) due to service of earlier event(s). This happens when the following
conditions are true:
1. UART1 events are serviced by interrupt (i.e. flags are checked and cleared
only in the interrupt routine ISR),
2. Either RI or TI is set at any one time throughout the ISR (even while the
other is cleared) such that at least one of the flags is still set after reti,
causing the UART1 request line, which is an OR-function of the two flags RI
and TI, to remain set throughout the ISR and after reti.
Two example scenerios are illustrated in the following figure: RI
TI
OR
interrupt
detection
TI
RI
request
ISR entered
ISR exited
TI
RI
request
E.g. 1
E.g. 2
Errata Sheet
Functional Deviations
XC888CLM-8FF, ES AB
7/25
Rel. 1.0, 05.06.2006

Figure 2
This means, any future UART1 RI or TI event is not able to cause a rising edge
and therefore not able to trigger an interrupt request to the core as if the
UART1 interrupts had been disabled, until both RI and TI flags are cleared at
some time. The clearing of flags would have to be done by users code
additionally outside of the UART1 interrupt routine, which is however normally
not feasible with an interrupt service scheme.
Workaround
There are two suggested workaround:
1. If other events of interrupt node XINTR8 (EX2) need not be enabled for
interrupt, disable this interrupt node and use software polling of the flags
instead.
2. Before return from interrupt, check again if RI or TI is (still) set (due to new
request since the last check). If so, jump and execute the ISR routine from
start. Exit only when all flags are checked to be cleared. However, dummy
interrupt of the node may occur after return from interrupt, and should be
ignored. Another drawback is if UART1 events are occurring at high rate, the Errata Sheet
Functional Deviations
XC888CLM-8FF, ES AB
8/25
Rel. 1.0, 05.06.2006

CPU may be stuck in the service routine of the UART1 interrupt for a long
time.
<entry point of interrupt node service routine>
..
Start:
check flag RI
..
clear flag RI
..
check flag TI
..
clear flag TI
..
Finish:
if RI or TI is set, jump to Start
reti (return from interrupt)
Figure 3
INT_XC8.005 Write to IRCON0 Blocks Interrupt Request of External Inter-
rupt 0,1
Any write (read-modify-write or direct MOV) to the SFR IRCON0 will block an
incoming interrupt request from external interrupt 0 or 1, even though the
respective flag (EXINT0 or EXINT1) is set.
Workaround
After any write to the IRCON0, check (read IRCON0) the flags EXINT0 and
EXINT1. If any flag is set, run the service routine; otherwise proceed.
In case of enabled for interrupt, the service routine should be duplicated: one
copy as the interrupt service routine (with reti executed); another copy in main
code memory for software call (with ret executed). Errata Sheet
Functional Deviations
XC888CLM-8FF, ES AB
9/25
Rel. 1.0, 05.06.2006

MultiCAN_TC.025
RXUPD
behavior
When a CAN frame is stored in a message object, either directly from the CAN
node or indirectly via receive FIFO or from a gateway source object, then bit
MOCTR.RXUPD is set in the message object before the storage process and is
automatically cleared after the storage process.
Problem description
When a standard message object receives a CAN frame from a CAN node, then
it processes its own RXUPD as described above (correct).
In addition to that, it also sets and clears bit RXUPD in the message object
referenced by pointer MOFGPR.CUR (wrong behavior).
Workaround
The foreign RXUPD pulse can be avoided by initializing MOFGPR.CUR with the
message number of the object itself instead of another object (which would be
message object 0 by default, because MOFGPR.CUR points to message object
0 after reset initialization of MultiCAN).
MultiCAN_TC.026 MultiCAN Timestamp Function
The timestamp functionality does not work correctly.
Workaround
Do not use timestamp.
MultiCAN_TC.027 MultiCAN Tx Filter Data Remote
Message objects of priority class 2 (MOAR.PRI = 2) are transmitted in the order
as given by the CAN arbitration rules. This implies that for 2 message objects
which have the same CAN identifier, but different DIR bit, the one with DIR = 1
(send data frame) shall be transmitted before the message object with DIR = 0,
which sends a remote frame. The transmit filtering logic of the MultiCAN leads Errata Sheet
Functional Deviations
XC888CLM-8FF, ES AB
10/25
Rel. 1.0, 05.06.2006

to a reverse order, i.e the remote frame is transmitted first. Message objects
with different identifiers are handled correctly.
Workaround
None.
MultiCAN_TC.028
STD
behavior
Correct behavior
Standard message objects:
MultiCAN clears bit MOCTR.MSGVAL after the successful
reception/transmission of a CAN frame if bit MOFCR.SDT is set.
Transmit Fifo slave object:
MultiCAN clears bit MOCTR.MSGVAL after the successful
reception/transmission of a CAN frame if bit MOFCR.SDT is set. After a
transmission, MultiCAN also looks at the respective transmit FIFO base object
and clears bit MSGVAL in the base object if bit SDT is set in the base object and
pointer MOFGPR.CUR points to MOFGPR.SEL (after the pointer update).
Gateway Destination/Fifo slave object:
MultiCAN clears bit MOCTR.MSGVAL after the storage of a CAN frame into the
object (gateway/FIFO action) or after the successful transmission of a CAN
frame if bit MOFCR.SDT is set. After a reception, MultiCAN also