NXP® SemiconductorsMSE9S12XEP100_0M22E
Mask Set ErrataRev. April 17, 2012



MC9S12XEP100, Mask 0M22E


Introduction
This errata sheet applies to the following devices:

MC9S12XEP100



MCU Device Mask Set Identification

The mask set is identified by a 5-character code consisting of a version number, a letter, two numerical digits, and a letter, for example 1K79X. All standard devices are marked with a mask set number and a date code.



MCU Device Date Codes

Device markings indicate the week of manufacture and the mask set used. The date is coded as four numerical digits where the first two digits indicate the year and the last two digits indicate the work week. For instance, the date code "0201" indicates the first week of the year 2002.



MCU Device Part Number Prefixes

Some MCU samples and devices are marked with an SC, PC, or XC prefix. An SC prefix denotes special/custom device. A PC prefix indicates a prototype device which has undergone basic testing only. An XC prefix denotes that the device is tested but is not fully characterized or qualified over the full range of normal manufacturing process variations. After full characterization and qualification, devices will be marked with the MC or SC prefix.



Errata System Tracking Numbers

MUCtsXXXXX is the tracking number for device errata. It can be used with the mask set and date code to identify a specific erratum.



Errata Summary


Errata NumberModule affectedBrief DescriptionWork-
around
MUCts03187 ftm FTM: Read Margin level incorrect after Program and Page Erase operations. YES
MUCts03228 ftm FTM: Incorrect IFR read NO
MUCts03230 ftm FTM: User command generated ACCERR flag blocks EEE operation YES
MUCts03231 ftm User Command generated ACCERR flag blocks EEE operation YES
MUCts03232 ftm FTM: Enable D-Flash Command can corrupt EEE if Data Flash not Erased YES
MUCts03255 mcu_9s12xep100 MCU: 50MHz operation not guaranteed over whole specification range YES
MUCts03261 s12x_cpu DBG Wrong trace buffer entries during stretched bus cycles NO
MUCts03270 s12xe_crg CRG: STOP deadlock on FTM activity YES
MUCts03271 s12x_dbg DBG writing to DBGMFR corrupts DBGSCR3 YES
MUCts03310 s12x_dbg DBG 'outside range' mode databus qualification ignored YES
MUCts03311 s12x_dbg DBG Range Mode TAGB and TAGD influence in range modes YES
MUCts03331 pads_ll18 PADS Power up at hot not possible NO
MUCts03338 s12x_dbg DBG: Normal/Loop1 mode first trace buffer entry zero NO
MUCts03344 s12x_cpu S12X_CPU : CALL Instruction, wrong PC relative addressing YES
MUCts03346 s12xep100_pti PS1 Wired-OR function not working YES
MUCts03355 s12x_cpu S12X_CPU: tagged breakpoint generated when instruction is not executed NO
MUCts03357 s12x_cpu S12X_CPU: CPU ignores tag hit NO
MUCts03364 s12x_cpu CPU: CPU does not discard tag of PAGE2 opcode in PAGE2 instruction YES
MUCts03412 s12x_dbg DBG No address match if next transaction is misaligned word access YES
MUCts03421 s12x_dbg DBG: Pure PC mode too many trace buffer entries NO
MUCts03430 adc_12b16c ADC: Converting (vrh-vrl)/4 value on any channel can generate an incorrect result NO
MUCts03439 iic IIC: 10-bit Slave is misaddressed by the data YES
MUCts03446 iic IIC:10-Bit Slave fails to acknowledge address on a second transfer YES
MUCts03447 iic IIC:10-bit Master addresses itself by a faulty acknowledge NO
MUCts03449 iic IIC: 10-bit Slave does not acknowledge address if the last data is $XF YES
MUCts03494 adc_12b16c ADC: The SCF flag does not get set during continuous conversions YES
MUCts03563 mscan MSCAN: Corrupt ID may be sent in early-SOF condition YES
MUCts03690 s12x_int INT: Incorrect resolution of Non-maskable Exceptions NO
MUCts03704 vreg_3v3_ll18 VREG: Output waveform at pin incorrect. for APIEA=1, APIES=1, APIFE=1; YES
MUCts03709 vreg_3v3_ll18 VREG: Possible incorrect operation if device is wakened from stop mode within 4.6us of stop mode entry NO
MUCts03757 s12x_dbg DBG: State flags and counter corrupted by simultaneous arm and disarm YES
MUCts03797 adc_12b16c ADC: converting value (Vrefh-Vrefl)/4 could give wrong result YES
MUCts03977 pwm_8b8c PWM: Emergency shutdown input can be overruled YES
MUCts04081 pim_xe PIM: Edge-sensitive mode of IRQ-pin may cause incorrect interrupt vector fetch YES
MUCts04104 ect_16b8c ECT: Channel 0 - 3 Input Capture interrupts inhibited when BUFEN=1, LATQ=0 and NOVWx=1 YES
MUCts04135 pwm_8b8c PWM: Wrong output level after shutdown restart in 16bit concatenated channel mode YES
MUCts04136 pwm_8b8c PWM: Wrong output value after restart from stop or wait mode YES
MUCts04156 ect_16b8c ECT_16B8C: Output compare pulse is inaccurate YES
MUCts04157 tim_16b8c TIM_16B8C: Output compare pulse is inaccurate YES
MUCts04179 s12xe_crg s12xe_crg: Possible PLL premature LOCK followed by an UN-LOCK in conjunction with STOP instruction YES
MUCts04244 sci SCI: RXEDGIF occurs more times than expected in IR mode YES



FTM: Read Margin level incorrect after Program and Page Erase operations.MUCts03187

Description

The following memory controller commands modify the read margin level 

but do not clear the final Margin read level used for the command
verify stage on command completion.

“Program P-Flash”
“Erase P-Flash Sector”
“Program D-Flash”
“Erase D-Flash Sector”

This will means that any follow up CPU reads will be at that final
margin level.

The margin level will be cleared on the next reset sequence by
default.



Workaround


No action is necessary for normal execution from the Flash.  If a read 

to a specific margin level is required the margin level should be set
explicitly with the “Set Margin User Level” command following any
program or erase operations.




FTM: Incorrect IFR readMUCts03228

Description

Internal memory controller reads are mapped incorrectly such that 

resultant data is incorrect. This impacts the following areas:

(1) Reset sequence reading timing parameters. Default timing
parameters in the ROM are used. The MSTAT0 & MASTAT1 bits always
indicate an error status following reset due the read of the incorrect
data.

(2) “Program Once” and “Read Once” commands fail.



Workaround


Do not use Program Once and Read Once commands. 


When launching the first command on the memory controller following
reset allow for the MSTAT bits to be set by the read error.






FTM: User command generated ACCERR flag blocks EEE operationMUCts03230

Description

This is a documentation error. 


Preliminary documentation describes the Reset condition for the
MGSTAT1 and MGSTAT0 bits in the FSTAT register as = 0. In fact the
MGSTAT bits out of reset will reflect the result of the implicit reset
operation of the memory controller.


Workaround


Application code can decode the status of the MGSTAT0 and MGSTAT1 bits 

following reset.




User Command generated ACCERR flag blocks EEE operationMUCts03231

Description

A Flash CCOB command resulting in an Access Error (ACCERR) is flagged 

in an internal status register, as well as the FSTAT register. The
internal status register is not cleared by the EEE system which can
cause the EEE operation to fail.

Outstanding tags will not be correctly processed into records within
the D-Flash. Hence data written to the buffer RAM will not be
available on subsequent resets. This condition is flagged by the
PGMERIF flag being set in the FERSTAT register.




Workaround


If using the EEE, pause the EEE with the “Disable EE Emulation” 

and “Enable EE Emulation” commands around any CCOB commands.




FTM: Enable D-Flash Command can corrupt EEE if Data Flash not ErasedMUCts03232

Description

The “Enable D-Flash” command can cause corrupted EEE records if the 

EEE system is not completely erased.

The “Enable D-Flash” command is used (in special modes only) to
partition the EEE.
Preliminary documentation describes this command as being only allowed
to be executed once. In fact it can be run any number of times during
development to re-size the EEE.

In the case that the existing EEE configuration is not completely
erased it will cause corruption of the EEE record system.



Workaround


Always execute the “Erase All Blocks” command immediately prior to any 

execution of the “Enable D-Flash” command. This will ensure that the D-
flash is completely erased before formatting the EEE.




MCU: 50MHz operation not guaranteed over whole specification rangeMUCts03255

Description

The targeted 50MHz bus frequency is not guaranteed on the 0M22E mask 

set across the full operating range.

Slow process material may fail under high temperature and low
VDDR/VDDA supply voltage operating conditions.

40MHz bus frequency can be guaranteed over the whole specification
range

50MHZ operation can typically be attained at room temperature with
VDDA/VDDR levels of 5V.



Workaround


Do not exceed 40MHz when operating at high temperature and low voltage.


Limit temperature and voltage range when operating at 50MHz.



DBG Wrong trace buffer entries during stretched bus cyclesMUCts03261

Description

This is a debug issue only.


If a CPU bus cycle is requested, but not acknowledged immediately, a
wrong trace buffer entry may happen.

Example scenario:
XGATE accesses PRR -> CPU is not immediately acknowledged.

Frequency of occurrence:
This issue will only manifest during BDM steal or XGATE
PRR access during trace capture.


Workaround


None. 




CRG: STOP deadlock on FTM activityMUCts03270

Description

If the memory controller is busy or has pending EEE tags, entering Stop

mode can cause a condition where Stop mode cannot be exited.

Workaround


Ensure that all pending FTM activity is completed before entering Stop mode.


In the case that there are pending EEE tags either wait for the TAG
counter to clear or execute the "Disable EE Emulation" command before
entering Stop.



DBG writing to DBGMFR corrupts DBGSCR3 MUCts03271

Description

Writing to the read only register DBGMFR actually performs a write

access of DBGSCR3.

Thus DBGSCR3 is loaded with the data of the attempted write to DBGMFR.
DBGMFR cannot be written and is thus not affected.

Workaround


Do not write to the read only register DBGMFR. 




DBG 'outside range' mode databus qualification ignoredMUCts03310

Description

When using a comparator pair for a range comparison, the databus can

also be used for qualification by using the comparator A/C data and
data mask registers. This does not work correctly.

Scenario:
With CompA/CompB in 'outside range' mode an access to a memory location
with an address above the high boundary of CompB always generates a
comparator match. The data qualification is not carried out.

If the accessed memory is located below the address defined in CompA,
the behavior is correct.

CompC/CompD behavior is the same.


Workaround


Using 2 comparator pairs configured for inside range mode an outside

range match with databus qualification can be generated.

MAP
0x000000 |COMPA|
| | Inside Range A/B with DB qualification
ADDRESSX |COMPB|
| |
ADDRESSY |COMPC|
| | Inside Range C/D with DB qualification
0x7FFFFF |COMPD|



DBG Range Mode TAGB and TAGD influence in range modesMUCts03311

Description

The comparator A and C TAG bits are used to tag range comparisons for

the AB and CD ranges respectively. The comparator B and D TAG bits
should have no effect in range modes. However the TAGB/TAGD bits do
have
an effect.
If the A/C TAG bit is 0 but the paired B/D TAG bit is set, a valid
match
may be missed.


Workaround


Clear TAGB when configured for forced range mode comparisons using CompAB 

Clear TAGD when configured for forced range mode comparisons using CompCD



PADS Power up at hot not possibleMUCts03331

Description

Power-up of the device above 125 degC is not possible. The ESD 

protection circuitry can latch on during power-up above this
temperature causing very high Idd (in the Amps range).

Workaround


None. 




DBG: Normal/Loop1 mode first trace buffer entry zeroMUCts03338

Description

With the DBG module configured for Normal/Loop1 mode end aligned tracing.


If the DBG is armed by an XGATE write to DBGC1 and simultaneously a
source COF instruction is executed by the S12X_CPU, then the first trace
buffer entry is 0.


Workaround


None. 




S12X_CPU : CALL Instruction, wrong PC relative addressingMUCts03344

Description

The effective address calculated by the CALL instruction using PC

relative addressing is one / two less than it should be.
With the result that the CALL ends one / two byte(s)
before the intended destination.

Affected indexed addressing modes:
IDX 5-bit offset
1 less
IDX Accumulator offset
1 less
IDX1
2 less









Workaround


Take into account the extra constant offsets when using PC relative

addressing of CALL.





PS1 Wired-OR function not workingMUCts03346

Description

Writing to Port S Wired-Or Mode Register (WOMS) bit1 has no effect and 

the high drive output transistor of PS1 remains active.
PS1 (SCI0/TXD) cannot be configured for wired OR operation.


Workaround


For SCI wired OR operation the following can be used 

SCI2 mapped to PS[3:2]
SCI3 mapped to PM[7:6]
SCI[7:4] mapped to PL[7:0]



S12X_CPU: tagged breakpoint generated when instruction is not executedMUCts03355

Description

A tagged instruction that is in the S12X_CPU instruction queue but is 

not executed because of an interrupt can generate a taghit, causing a
wrong DBG state switch and possible breakpoint.

Scenario:
NOP
CLRA <- tagged instruction, not executed because of an IRQ
TAGHIT!
LDY VAL1 <- first instruction in interrupt service routine
RTI <- return from interrupt service routine
CLRA <- same instruction, now executed
TAGHIT!

For the DBG module it looks like the instruction is executed twice.
The state sequencer gets 2 taghits (for the same CLRA), which is wrong.



Workaround


None. 




S12X_CPU: CPU ignores tag hitMUCts03357

Description

Under the following condition, the CPU ignores a tag hit and executes

the tagged instruction when it should not:

1. The CPU has finished an instruction and is going to execute a page2
instruction next, prebyte 0x18 already in the instruction register...

2. ...at the same time an interrupt is pending, so the CPU does not
execute the page2 instruction, but starts to perform the Interrupt
sequence "VSPSSPSSP".

3. The first instruction of the Interrupt Service Routine has been
tagged and the corresponding taghit action is asserted, so the CPU
should not execute the tagged instruction, but start a SWI/BDM
sequence.
But this does not happen, the tag is ignored and the instruction is
executed.


Workaround


None. 




CPU: CPU does not discard tag of PAGE2 opcode in PAGE2 instructionMUCts03364

Description

If the byte after a PAGE2 switch is tagged, the tag generates a taghit.

Expected behavior would be that this tag is discarded. Example:

| MOVW #opr16i, opr16a | IMM-EXT | 18 03 jj kk hh ll | OPWPO |

If the PAGE2 switch ($18) is tagged (which means that
"the instruction is tagged", a taghit occurs, which is correct.

If the PAGE2 opcode itself (in this case the 03 for MOVW) is tagged, a
taghit does also occur, which is wrong.

The DBG module expects only taghits on instruction boundaries.

A PAGE2 switch + PAGE2 opcode is seen as a single instruction.

This behavior can led to an unexpected switching of the state sequencer
in the DBG module.

Workaround


None. 




DBG No address match if next transaction is misaligned word accessMUCts03412

Description

Memory accesses in successive bus cycles must both be able to generate

forced triggers if both accesses match.

If accesses occur in successive cycles whereby the second access is a
misaligned word access, then a comparator match is lost. This could
cause a forced breakpoint to be missed if the state sequencer is
dependent on both the successive matches to reach final state.
Example...
LDX #WORD_MISALIGNED
STD 0,X ; First access M0->State2
LDD WORD_MISALIGNED ; Second access M0->Final State

If the STD last bus cycle is a write and the LDD first bus cycle is a
read then only one state sequencer transition occurs.

In range modes, this can occur when 2 different addresses within/outside
the specified range are accessed in successive bus cycles, otherwise it
can only happen if the same address is written and then read in
successive bus cycles.

Workaround


Insert a NOP instruction before misaligned word accesses if they can 

follow accesses to the predefined comparator range.


LDX #WORD_MISALIGNED-1
STD 0,X ; First access in range M0->State2
NOP ; NOP insertion
LDD WORD_MISALIGNED ; Second access in range M0->Final
State




DBG: Pure PC mode too many trace buffer entriesMUCts03421

Description

If configured for Pure PC mode tracing then an extra, unexpected trace

buffer entry may be encountered, by one of the 2 following scenarios.

1) At a tagged breakpoint to the CPU the trace buffer stores the opcode
address of the tagged instruction although it is not executed.

2) When a BACKGROUND command forces BDM the address of the first opcode
following BDM is stored to the trace buffer befored entering BDM.

In both cases the extra trace buffer entry is of the first opcode
address following the breakpoint routine. Thus if tracing is not
terminated in the breakpoint routine, then the same entry appears twice
in the trace buffer.
If tracing is terminated in the breakpoint routine, the last trace
buffer entry is incorrect, since it points to the next instruction,
which has not yet been executed.


Workaround


None. 




ADC: Converting (vrh-vrl)/4 value on any channel can generate an incorrect resultMUCts03430

Description

When converting the exact analog value (vrh-vrl)/4 the result in the 

result register might be far higher than the expected 1024. This due
to the fact that the successive approximation conversion is sensitive
to noise at exactly this value. Slightly higher or lower analog values
will generate correct results.

Workaround


None. 




IIC: 10-bit Slave is misaddressed by the dataMUCts03439

Description

10-bit Master-Transmitter, Slave-Receiver transfer - The Slave fails 

to acknowledge if the first data byte is the equivalent of the third
address byte in a Master-Receiver, Slave-Transmitter transfer.

Example:
Where the slave address is 0x2AA and the first data byte value is
0xF5.

The first address byte is 0xF4 and the second is 0xAA. If the master
sends 0xF5 as the first data byte (which is the same as the first byte
except the last R/W bit) the slave is misaddressed and does not
acknowledge the following data transfer.

This will cause communications failure.


Workaround


Avoid using a first data byte value that is the same as the third 

address byte. Where possible use dummy data for the first byte which
does not match the address byte.



IIC:10-Bit Slave fails to acknowledge address on a second transferMUCts03446

Description

10-bit Master-Receiver, Slave-Transmitter transfer - When a part is 

configured as a slave it fails to acknowledge the second byte of the
extended address on the second attempt of a Master-Receiver addressing
a Slave-Transmitter. The first transfer will be successful but the
second will fail.

This will cause communications failure.



Workaround


When configuring the IIC as a Receiver (Tx/Rx = 0), first disable the 

IIC (IBEN = 0), re-enable it (IBEN = 1) and then clear the Tx/Rx bit.



IIC:10-bit Master addresses itself by a faulty acknowledgeMUCts03447

Description

10-bit Master-Transmitter, Slave-Receiver transfer - The Master does 

not release SDA when waiting for the Slave to acknowledge if the
Master's address = 0x1XX.

Example:
Address of the master is $1AA and the address of the slave is $155. As
the first address byte is $F2, the master and the slave both
acknowledge.

This will cause communications failure.


Workaround


None. 




IIC: 10-bit Slave does not acknowledge address if the last data is $XFMUCts03449

Description

10-Bit Master-Receiver, Slave-Transmitter transfer - The Slave fails 

to acknowledge the address if the last data byte in a previous
transfer was 0xXF.

Example:
First initiate a Master Tx Slave Rx operation

Start
0xF0+AD10+AD9+R/W=0 (First Address byte = 0xF2)
Acknowledge
AD8:1 (Second Address byte = 0x78)
Acknowledge
Data1 (0x01)
Acknowledge
Data2 (0x0F)
Acknowledge
Stop

Secondly initiate a Master Rx Slave Tx operation

Start
0xF0+AD10+AD9+R/W=0 (First Address byte = 0xF2)
Acknowledge
AD8:1 (Second Address byte = 0x78)
NO ACKNOWLEDGE ¡­¡­. Fault condition

This will cause communications failure.


Workaround


Avoid using last data bytes in transfers in the range 0xXF; where 

possible add a dummy data byte.




ADC: The SCF flag does not get set during continuous conversionsMUCts03494

Description

When the ATD is configured for continuous conversions (SCAN bit = 1 in 

ATDxCTL5) the sequence complete flag (SCF) does not get set and
no SCF interrupt will be generated.





Workaround


1) Where interrupt service of the ATD is used, do not use continuous 

conversion mode. Relaunch single conversion sequences by re-writing
ATDxCTL5 with SCAN=0 in the interrupt service routine to generate a
continuous train of conversion sequences.

2) Where using continuous conversion (SCAN bit = 1 in ATDCTL5
register) poll the CCF flags in ATDSTAT2 and ATDSTAT1 to track which
conversions already have finished. The Sequence Complete Interrupt can
not be used as the SCF flag will never set.






MSCAN: Corrupt ID may be sent in early-SOF conditionMUCts03563

Description

The initial eight ID bits will be corrupted if a message is set up for

transmission during the third bit of INTERMISSION and a dominant bit is
sampled leading to an early-SOF*.

The CRC is calculated from the resulting bit stream so that the
receiving nodes will still validate the message.

An early-SOF condition may only occur if the oscillators in the network
operate at a tolerance range which could lead to a cumulated phase error
after 11 bit times larger than phase segment 2.

In case arbitration is lost during transmission of the corrupt
identifier, a non-corrupted ID will be sent with the next attempt if the
transmit request remains active.

*The CAN protocol condition referred to as 'early-SOF' in this erratum
is detailed in "Bosch CAN Specification Version 2.0" Part A, section 9,
and a Note to section 3.2.5 INTERFRAME SPACING – INTERMISSION in Part B.

Workaround


Due to increased oscillator tolerance a transmission start in the third

bit of intermission is possible and allowed. The errata can be avoided
when calculating the maximum oscillator tolerance of the overall CAN
system. The phase error after 11 bit times due to the oscillator
tolerance should be smaller than phase segment 2.

If an early-SOF cannot be avoided the following methods will provide
prevention:

- Assigning the same value to all upper eight ID bits in the network
- Allocating dedicated data length codes (DLC) to every identifier used
in the network and checking for correspondence after reception
- Assigning only IDs (x) which do not consist of a combination of other
assigned IDs (y,z) and using the acceptance filters to reject
erroneous messages, i.e.
- for standard frames: IDx[11:0] != {IDy[11:3], IDz[2:0]}
- for extended frames: IDx[28:21] != {IDy[28:21],IDz[20:0]}



INT: Incorrect resolution of Non-maskable ExceptionsMUCts03690

Description

The internal priority for the software exceptions (TRAP, BGND, SWI, 

SYS) is incorrect in relation to other non-I-bit maskable interrupt
requests. There are two scenarios for the resulting behaviour:

Scenario (1)
The internal priority of the software exceptions is lower than the
priority of the MPU error and XGATE error exceptions. This leads to
problems, if the MPU error interrupt request or the XGATE error
interrupt request and the vector request for one of the software
exceptions occur in the same cycle:

In case of a TRAP, SWI or SYS vector request occurring in the same
cycle as the MPU error interrupt request or the XGATE error interrupt
request, the CPU will get the MPU error vector address or the XGATE
error vector address instead. The software exception will be lost.

In case of a BGND vector request occurring in the same cycle as the MPU
error interrupt request or XGATE error interrupt request, the CPU will
get the MPU error vector address or XGATE error vector address instead
of the BGND vector address. Since the BDM firmware ROM is already
inserted into the memory map, the vector address comes from the
respective locations in the BDM firmware ROM instead of the regular
memory locations. This results in a code run-away situation for the CPU.

Scenario (2)
The priority of the SYS software exception is lower than the priority
of the XIRQ. In the case of a SYS vector request occurring at the same
cycle as the XIRQ vector request, the CPU will get the XIRQ vector
address instead.
In this case, the XIRQ interrupt service routine is actually entered
twice due to the first interrupt really being the SYS exception but
with the wrong vector address (XIRQ).
The SYS instruction will be lost.


Workaround


Scenario (1)

None.

Scenario (2)
Since the SYS instruction does not set the X-bit, the incorrectly taken
XIRQ interrupt service routine is entered again immediately after the
interrupt stacking sequence ended. This situation can be used to check
in the XIRQ interrupt service routine if the problem has occurred: if
the return address in the exception stack-frame points to the entry of
the XIRQ service routine, it was entered twice (and SYS was not
executed correctly) and the return address can be modified to jump to
the SYS interrupt service routine.



VREG: Output waveform at pin incorrect. for APIEA=1, APIES=1, APIFE=1;MUCts03704

Description

If the APIEA, APIES and APIFE bits are all set in order to output a 

clock with twice the selected API Period at the external pin the
waveform at the pin can be incorrect.


Workaround


1) If using only positive edges of the output waveform is acceptable, 

then use APIEA=1, APIES=0, APIFE=1 to output pulses at the API period.

2) If a square wave at twice the API frequency is required either:
a) Use the API interrupt to generate the waveform at an external pin
via software / GPIO functionality.
b) Use APIEA=1, APIES=0, APIFE=1 and connect a T-flip-flop externally
to generate the waveform.





VREG: Possible incorrect operation if device is wakened from stop mode within 4.6us of stop mode entryMUCts03709

Description

A very low probability exists that after the device enters stop mode it

may reset rather than wake up normally upon reception of the wake-up
signal. This will only happen providing all of the following conditions
are met:

1) Device is powered by the on-chip voltage regulator
2) Device enters stop mode
3) The wake-up signal is activated within a specific very short window
(typically 11ns long, not longer than 20ns). Position of the window
varies between different devices, however it never starts sooner than
1.6us and never ends later than 4.7us after the stop mode entry. 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.

If this incorrect behaviour occurs, the device will indicate the low
voltage reset (LVR) as the reset source. The device will operate
normally after the reset.

Stop mode entry can be:

1) S12: Execution of STOP instruction by the CPU (providing the S-bit in
CCR is cleared)
2) S12X: (1) or End of XGATE thread (providing the CPU is in stop mode)
3) S12XE: (2) or End of CCOB command executed by the NVM state-machine
(providing the CPU is in stop mode and XGATE is idle)

The incorrect behaviour 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).

Workaround


None. 




DBG: State flags and counter corrupted by simultaneous arm and disarmMUCts03757

Description

Simultaneous disarming (hardware) and arming (software) results in 

status, flag and counter register (DBGSR, DBGMFR, DBGCNT) corruption.

Hardware disarming initiated by an internal trigger or by tracing
completion takes 2 clock cycles. If a write to DBGC1 with the ARM bit
set occurs in the final clock cycle of this disarming process, arming
is suppressed but the DBGSR register is initialized to state1 and
DBGMFR/DBGCNT are initialized to zero.

The result is that the DBG module is disarmed by hardware but DBGSR
indicates state1.

NOTE: DBGC1 is typically only written to whilst armed to set the TRIG
bit or update the COMRV bits to map different registers to the address
map window.

Generally during debugging, after arming the DBG module and returning
to application code a further write access of DBGC1 over the BDM
interface requires considerable time relative to application code
execution, therefore in many cases the breakpoint may be reached before
a DBGC1 update is attempted. Furthermore the probability of hitting the
same cycle is seen to be very low.


Workaround


If the fault condition is caused by writing to DBGC1 to set the TRIG 

bit (to request an immediate breakpoint), then the application code may
be rerun again without the attempted setting of TRIG. The software
trigger (TRIG) is unnecessary in any case at the same point point in
time as an internal hardware trigger occurs.

Development tool vendors should avoid COMRV updates while the DBG is
armed.

Users that observe the problem due to development tool COMRV updates
can add a NOP to code and rerun to shift the disarm cycle, thereby
preventing a collision with the COMRV updates.



ADC: converting value (Vrefh-Vrefl)/4 could give wrong resultMUCts03797

Description

When the Analogue to Digital Converter converts an analogue value of

(Vrefh-Vrefl)/4 on any ADC channel, there is a risk to get a wrong value.

When noise occurs on the input, the highest bit of the conversion result
can be erroneously set.
This is because internal voltage comparators are asynchronous to the ADC
clock.
The error can only occur on the most significant bit when the conversion
result is measured as (Vrefh-Vrefl)/4 exactly.

The error always occurs on a unique value depending on the conversion mode:
- For 12-bit conversion if the result value is 1024 the ADC will
erroneously report a result of 2048.
- For 10-bit conversion if the result value is 256 the ADC will
erroneously report a result of 512.
- For 8-bit conversion if the result value is 64 the ADC will
erroneously report a result of 128.



Workaround


It is not possible to avoid the error occurring, however, it is possible

to minimize or avoid the effects of the error by using one of the
following methods:

- Reject values outside a determined sigma. For instance, when
monitoring slow-moving voltages (i.e. battery level), the software can
discard a conversion result which is greatly different from the previous
result and is the erroneous value.

- Simply discard conversion results of 2048 in 12-bit mode, 512 in
10-bit mode and 128 in 8-bit mode and use the previous result.

- Launch a new conversion when the conversion result is 2048 in 12-bit
mode, 512 in 10-bit mode and 128 in 8-bit mode and use the new result.



PWM: Emergency shutdown input can be overruledMUCts03977

Description

If the PWM emergency shutdown feature is enabled (PWM7ENA=1) and PWM

channel 7 is disabled (PWME7=0) another lower priority function
available on the related pin can take control over the data direction.
This does not lead to a problem if input mode is maintained. If the
alternative function switches to output mode the shutdown function may
unintentionally be triggered by the output data.


Workaround


When using the PWM emergency shutdown feature the GPIO function on the

pin associated with PWM channel 7 should be selected as an input.

In the case that this pin is selected as an output or where an
alternative function is enabled which could drive it as an output,
enable PWM channel 7 by setting the PWME7 bit. This prevents an
active shutdown level driven on the (output) pin from resulting in an
emergency shutdown of the enabled PWM channels.




PIM: Edge-sensitive mode of IRQ-pin may cause incorrect interrupt vector fetchMUCts04081

Description

Where the IRQ interrupt is being used in edge-sensitive mode and a 

lower priority interrupt is already pending when an IRQ edge event
occurs, if the IRQ edge event occurs inside a very narrow (<3ns) window
just as the pending interrupt vector is being fetched, then a different
vector other than that relating to either the pending interrupt or IRQ
will be taken.

In the case that a programmed interrupt vector is fetched both the
originally pending interrupt and the IRQ interrupt request will remain
pending and will be serviced once the erroneously called service
routine has completed (and RTI has been executed).

In the case that the incorrect vector fetch is from an unprogrammed
vector table entry (i.e. erased state = 0xFFFF) then erroneous
execution from the start of the register space will occur most often
resulting in an illegal memory access reset, COP reset or Unimplemented
Instruction Trap occurring.

In the less likely case that one of the three reset vectors is
incorrectly fetched then execution will jump to the appropriate reset
code.

The following vectors are not affected will not cause erroneous
behavior if pending:
$F0 - RTI
$F6 - SWI
$E2 – ECT channel 6
$B2 – CAN0 Rx
$72 – XGATE software trigger 0

This issue is limited to the edge-sensitive mode of the IRQ input only -
applications not using IRQ interrupts or configured for level-
sensitive IRQ input are not affected.

There is no issue where a pending interrupt has higher priority than
the IRQ request.

Workaround


Where using IRQ in edge-sensitive mode then configure the interrupt 

priority levels of all interrupts being used to ensure that the IRQ
request always has the lowest priority.

For new designs, where possible use the IRQ input in level-sensitive
mode or alternatively use a key-interrupt port.

There are a number of ‘best practices’ and features of the S12X which
can help minimize the impact of this errata in the case of it occurring:

1) As ‘best practice’ initialize all unused and unimplemented/reserved
interrupt vector table locations to point to a dummy interrupt service
routine (terminated with an RTI).

2) Where possible, check for appropriate asserted flags in interrupt
service routines and return / flag a system error if no request flag is
set.

3) Support is provided on the MCU for managing the following system
conditions:
* COP watchdog reset
* Illegal access reset
* Unimplemented instruction trap
For ‘best practice’ the application's software should be written to
recover from any of these conditions in a controlled manner.

4) In the case of erroneous code execution jumping to unused Flash the
typical practice of filling all unused Flash and RAM space with the op-
code for the SWI instruction will help manage this. SWI exception
routine should be written in this case to manage this event.




ECT: Channel 0 - 3 Input Capture interrupts inhibited when BUFEN=1, LATQ=0 and NOVWx=1MUCts04104

Description

Channel 0 – 3 Input Capture interrupts are inhibited when BUFEN=1, 

LATQ=0 and NOVWx=1 if an Input Capture edge occurs during or between a
read of TCx and TCxH or between a read of TCx/TCxH and clearing of CxF.


Details:

When any of the buffered input capture channels 0 - 3 are configured
for buffered/queue mode (BUFEN=1, LATQ=0) each of the channel’s input
capture holding registers and each channel’s associated pulse
accumulator and its holding register are enabled. When the input
capture channel is enabled by writing to a channel’s EDGxB and EDGxA
bits, both the input capture and input capture holding register are
considered empty. The first valid edge received after enabling a
channel will latch the ECT’s free running counter into the input
capture register (TCx) without setting the channel’s associated CxF
interrupt flag. The second valid edge received will transfer the value
of the input capture register, TCx, into the channel’s TCxH holding
register, latch the current value of the free running timer into the
input capture register and set the channel’s associated CxF interrupt
flag. In this condition, both the TCx and TCxH registers are
considered ‘full’.

If a corresponding channel’s NOVWx bit in the ICOVW register is set,
the capture register or its holding register cannot be written by a
valid edge at the input pin unless they are first emptied by reading
the TCx and TCxH registers. The act of reading the TCx and TCxH
registers and clearing the channel’s associated CxF interrupt flag
involves three separate operations. Two 16-bit read operations and an 8-
bit write operation.

If a channel’s associated CxF interrupt flag is cleared before reading
the TCx and TCxH registers and if a valid input edge occurs during or
between the reading of the capture and holding register, a channel’s
associated CxF interrupt flag will no longer be set as the result of
valid input edges. For example:

Clear CxF
|
|
V
Read TCx <----+
| |
|<--------+--- Valid Input Edge Occurs
V |
Read TCxH <---+

If the TCx and TCxH registers are read before a channel’s associated
CxF interrupt flag is cleared and if a valid input edge occurs between
the reading of TCx/TCxH and the clearing of a channel’s associated CxF
interrupt flag, a channel’s associated CxF interrupt flag will no
longer be set as the result of valid input edges. For example:

Clear CxF
|
|
V
Read TCx
|
|<------------ Valid Input Edge Occurs
V
Read TCxH


Systems that service the interrupt request and read the TCx and TCxH
registers before the next valid edge occurs at a channel’s associated
input pin will avoid the conditions under which the errata will occur.

Workaround


A simple workaround exists for this errata:


1. Clear the input capture channel’s associated CxF bit.
2. Disable the input capture function by writing 0:0 to a channel’s
EDGxB and EDGxA bits.
3. Read TCx
4. Read TCxH
5. Re-enable the input capture function by writing to a channel’s EDGxB
and EDGxA bits.


Code Example:

unsigned char ICSave;
unsigned int TC0Val;
unsigned int TC0HVal;

ICSave = TCTL4 & 0x03; /* save state of EDG0B and EDG0A */
TFLG1 = 0x01; /* clear ECT Channel 0 flag */
TCTL4 &= 0xfc; /* disable Channel 0 input capture function */
TC0Val = TC0; /* Read value of TC0 */
TC0HVal = TC0H; /* Read value of TC0H */
TCTL4 |= ICSave; /* Restore Channel 0 input capture function */



PWM: Wrong output level after shutdown restart in 16bit concatenated channel modeMUCts04135

Description

When the PWM is used in 16-bit (concatenation) channel and the emergency

shutdown feature is being used, after de-asserting PWM channel 7
(note:PWMRSTRT should be set) the PWM channels do
not show the state which is set by PWMLVL bit when the 16-bit counter is
non-zero.




Workaround


If emergency shutdown mode is required:


In 16-bit concatenation mode, user can disable the related PWM
channels and set the corresponding general-purpose IO to be the PWM
LVL value. After a intend period, restart the PWM channels.





PWM: Wrong output value after restart from stop or wait modeMUCts04136

Description

In low power modes (P-STOP/STOP/WAIT mode) and during PWM7

de-assert and when PWM counter reaching 0, the PWM channel outputs
cannot keep the state which is set by PWMLVL bit.






Workaround


Before entering low power modes, user can disable the related PWM 

channels and set the corresponding general-purpose IO to be the PWM
LVL value. After a intend period, restart the PWM channels.








ECT_16B8C: Output compare pulse is inaccurateMUCts04156

Description

The pulse width of an output compare (which resets the free running

counter when TCRE = 1) will measure one more bus clock cycle than
expected.



Workaround


The specification has been updated. Please refer to revision V03.08 (04

May 2010) or later.

In description of bitfield TCRE in register TSCR2,a note has been added:
TCRE=1 and TC7!=0, the TCNT cycle period will be TC7 x "prescaler
counter width" + "1 Bus Clock". When TCRE is set and TC7 is not equal to
0, then TCNT will cycle from 0 to TC7. When TCNT reaches TC7 value, it
will last only one bus cycle then reset to 0.







TIM_16B8C: Output compare pulse is inaccurateMUCts04157

Description

The pulse width of an output compare (which resets the free running

counter when TCRE = 1) will measure one more bus clock cycle than
expected.



Workaround


The specification has been updated. Please refer to revision V02.07 (04

May 2010) or later.

In description of bitfield TCRE in register TSCR2,a note has been added:
TCRE=1 and TC7!=0, the TCNT cycle period will be TC7 x "prescaler
counter width" + "1 Bus Clock". When TCRE is set and TC7 is not equal to
0, then TCNT will cycle from 0 to TC7. When TCNT reaches TC7 value, it
will last only one bus cycle then reset to 0.







s12xe_crg: Possible PLL premature LOCK followed by an UN-LOCK in conjunction with STOP instructionMUCts04179

Description

If the PLL is manually turned off (PLLCTL_ PLLON = 0) before a STOP

instruction and the PLL is manually turned on (PLLCTL_PLLON=1) after
execution of the STOP instruction, the PLL might have a premature lock
condition in the case of a STOP instruction being executed with a
pending interrupt and the corresponding interrupt is enabled. In this
case the STOP is executed similar to NOP instruction.

Due to the manual control of the PLL, the VCO clock is switched on and
off. The PLL lock detection logic uses the VCO clock as well as the
reference clock (based on the external oscillator). The external
oscillator is not stopped because the STOP instruction is executed like
a NOP instruction, which keeps the reference clock running.

This causes the logic in the PLL lock detection being uncorrelated and
thus resulting in a possible premature LOCK condition (CRGFLG_LOCK=1).

After the next lock detection cycle the lock is lost (CRGFLG_LOCK=0)
because the VCO clock frequency has not reached the correct value. Some
lock detection cycles later the correct lock condition is reached (VCO
clock frequency reached the correct value) and the LOCK bit is set again
(CRGFLG_LOCK=1). Each transition of the LOCK bit is indicated by the
lock interrupt flag (CRGFLG_LOCKIF).

Workaround


Do not modify the PLLON bit around the STOP instruction. 


The clock control and power down/up sequencing is automatically done by
the device CRG module. Only the system clock source selection after exit
from STOP must be controlled by software (CLKSEL_PLLSEL bit) as
described in the Reference Manual.

Depending on the application if the fast wake-up feature is used the
software also needs to control the bit FSTWKP and bit SCME (both located
in the PLLCTL register) as described in the device Reference Manual when
STOP Mode is entered or exited.






SCI: RXEDGIF occurs more times than expected in IR modeMUCts04244

Description

Configured for Infrared Receive mode, the SCI may incorrectly set the 

RXEDGIF bit if there are consecutive '00' data bits. There are two
cases:

Case 1: due to re-sync of the RXD input, the received edge may be
delayed by one bus cycle. If an edge (bit = '0') is detected near
an SCI clock edge, the next edge (bit = '0') may be detected one
SCI clock later than expected due to re-sync logic.

Case 2: if external baud is slower than SCI receiver, the next edge
may be detected later than expected.

This glitch can be detected by the RXEDGIF circuit, but it does not
impact the final data result because the SCI receive and data recovery
logic takes samples at RT8, RT9, and RT10.




Workaround


Case 1 and case 2 may occurs at same time. To avoid those unexpected 

RXEDGIF at IR mode, the external baud should be kept a little bit
faster than receiver baud by:
P > (1/16)/(SBR)
or
(P)(SBR)(16)> 1

Where SBR is baud of receiver, P is external baud faster ratio.
For example:
1.- When SBR = 16, P = 0.4%, this means the external baud should be at
least 0.4% faster than receiver.
2.- When SBR = 4, P = 1.6%, this means the external baud should be at
least 1.6% faster than receiver.

Case 1 will cover case 2, i.e. case 1 is the worst case. If case1 is
solved, case 2 is also solved.


© NXP Semiconductors, Inc., 2012. All rights reserved.