NXP® SemiconductorsMSE9S12XF512_0M64J
Mask Set ErrataRev. April 16, 2012



MC9S12XF512, Mask 0M64J


Introduction
This errata sheet applies to the following devices:

MC9S12XF512, MC9S12XF384, MC9S12XF256, MC9S12XF128



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
MUCts03652 vreg_3v3_ll18 VREG: Possible incorrect operation if device is wakened from stop mode within 4.7µs of stop mode entry NO
MUCts03690 s12x_int INT: Incorrect resolution of Non-maskable Exceptions NO
MUCts03693 ftm_512k3 FTM: ECC faults not detected at the end of an erase verify range YES
MUCts03694 ftm_512k3 FTM: Access error flag not set by error on reading ERPART or DFPART values YES
MUCts03696 ftm_512k3 FTM: Memory controller stays busy if last available EEE D-Flash sector generates a fault YES
MUCts03697 ftm_512k3 FTM: Memory controller stays busy following reset if all available EEE D-Flash sectors are marked invalid YES
MUCts03700 ssram_e1_4096m16o8_ll18 RAM: System RAM can lock up on slow power up of the VDD core supply YES
MUCts03702 ssram_e16_2560m16o16_ll18 RAM: Memory Controller RAM can lock up on slow power up of the VDD core supply YES
MUCts03706 vreg_3v3_ll18 VREG: Output waveform at pin incorrect. for APIEA=1, APIES=1, APIFE=1; YES
MUCts03724 ftm_512k3 FTM: Erroneous Erase Verify P-Flash Section range does not flag error YES
MUCts03725 ftm_512k3 FTM RD1ALL command uses incorrect margin level to verify Data Flash IFR YES
MUCts03731 s12x_dbg DBG: State flags and counter corrupted by simultaneous arm and disarm YES
MUCts03796 adc_12b16c ADC: converting value (Vrefh-Vrefl)/4 could give wrong result YES
MUCts03852 ftm_512k3 FTM: EEPROM Emulation corruption on consecutive resets YES
MUCts03853 ftm_512k3 FTM: EEPROM Emulation Erroneous Dead Sectors NO
MUCts03854 ftm_512k3 FTM: EEPROM Emulation corruption on consecutive Enable EEPROM Emulation Commands YES
MUCts03859 mcu_9s12xf512 FTM: Version ID qualifier for FTM errata NO
MUCts03867 s12_cpu_xs CPU: Breakpoint missed at simultaneous taghits YES
MUCts03934 s12x_bdm BDM: Incomplete Memory Access on misaligned access due to BDM features YES
MUCts03984 ftm_512k3 FTM: EEE Brownout handling YES
MUCts04085 s12xf512_pim 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
MUCts04156 ect_16b8c ECT_16B8C: Output compare pulse is inaccurate YES
MUCts04177 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



VREG: Possible incorrect operation if device is wakened from stop mode within 4.7µs of stop mode entryMUCts03652

Description

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 event will only happen provided ALL of the following conditions are
met:
1) Device enters stop or pseudo-stop mode (see Stop mode entry
description below)
2) 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.

Stop or Pseudo-Stop mode entry are:
1) Execution of STOP instruction by the CPU (provided 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.
2) End of XGATE thread (providing the CPU is in stop or pseudo-stop
mode)
3) End of CCOB command executed by the NVM state-machine (provided
the CPU is in stop mode and XGATE is idle).

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.

Workaround


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.



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.



FTM: ECC faults not detected at the end of an erase verify rangeMUCts03693

Description

The memory controller can prematurely halt an erase verify in the case 

that an ECC single bit fault is detected in either of the last two
memory fields in the range being checked. On the P-Flash the field size
is a phrase (8 bytes), on the D-Flash it is a word (2 bytes).

In this case a double bit fault in the last or next to last field may
not be detected. Also any application count of single bit faults might
be incorrect. These scenarios would require multiple faults to occur in
the last three addresses in the memory region verified.

The following commands are affected:
Erase Verify All Blocks
Erase Verify Block
Erase Verify P-Flash Section
Erase All Blocks
Erase P-Flash Block
Erase P-Flash Sector
Un-secure Flash
Erase Verify D-Flash Section
Erase D-Flash Sector
Full Partition D-Flash
Enable EEPROM Emulation

Workaround


Any ECC faults in skipped locations will be detected and flagged during 

the verfy step of following Program operations.



FTM: Access error flag not set by error on reading ERPART or DFPART valuesMUCts03694

Description

In the case of an error reading the ERPART or DFPART values from the IFR

following Reset or after the following FTM commands the ACCERR and
MGSTAT flags are not set correctly.

The following commands are affected:
Enable EEPROM Emulation
Partition D-Flash
Full Partition D-Flash

Workaround


The EEPROM Emulation Query command reports the ERPART or DFPART values

that were last read by the above operations. Always run the EEPROM
Emulation Query command to verify the expected partition values
following reset and following the above commands.



FTM: Memory controller stays busy if last available EEE D-Flash sector generates a faultMUCts03696

Description

The memory controller remains busy (MGBUSY flag set) if all available 

EEE D-Flash sectors have been flagged as invalid. This can happen in
the case that an EEE write or erase activity generates a fault in the
last available valid sector and it is marked invalid.

This scenario can only happen if all sectors other than the erased
(READY) sectors have suffered from errors. If the partition defined
uses greater than 28 Data Flash sectors then this condition will be
indicated cleanly by setting of the ERSVIF0 flag.

This condition can only happen if all available EEE data sectors have
been flagged invalid which would be an extreme condition associated
with part being used well in excess of its normal operating life.

Workaround


Partition the Emulated EEPROM for >28 sectors of D-Flash (i.e. DFPART < 

99) and ensure that the ERSVIF0 flag is monitored (the associated
interrupt can be enabled).

In the case there are 28 D-Flash sectors or less allocated for EEE the
following considerations will avoid this condition:

(1) take care to not work the part in excess of its normal life.
(2) use the EEPROM Emulation Query command to monitor the number of
invalid (or 'dead') sectors after reset and flag a system error if the
number of invalid sectors exceed 25% of the total sectors allocated for
EEE.



FTM: Memory controller stays busy following reset if all available EEE D-Flash sectors are marked invalidMUCts03697

Description

The memory controller will remain busy (MGBUSY flag set) following 

reset if all available EEE D-Flash sectors have been have suffered
write or erase faults and have been flagged as invalid. This will
happen during the reset copy down of the EEE data in the case that all
available EEE D-Flash sectors have suffered from errors.

This scenario can only happen if all sectors other than the READY
sector have suffered from errors. If the partition defined uses greater
than 28 Data Flash sectors this condition will be flagged earlier as
the maximum number of invalid sectors (24) will have been violated and
flagged.

This condition could only happen if all sectors had become invalid
which would be an extreme condition associated with part being used
well in excess of its normal operating life.


Workaround


Partition the Emulated EEPROM for >28 sectors of D-Flash (i.e. DFPART < 

99) and ensure that the ERSVIF0 flag is monitored (the associated
interrupt can be enabled).

In the case there are 28 D-Flash sectors or less allocated for EEE the
following considerations will avoid this condition:

(1) take care to not work the part in excess of its normal life.
(2) use the EEPROM Emulation Query command to monitor the number of
invalid (or 'dead') sectors after reset and flag a system error if the
number of invalid sectors exceed 25% of the total sectors allocated for
EEE.



RAM: System RAM can lock up on slow power up of the VDD core supplyMUCts03700

Description

The system RAM can lock up on a slow power up of the VDD core supply

such that no RAM access is possible. The condition is not recoverable
until the device is powered down and powered up again with a faster VDD
power up. This behavior is more evident at high temperature.

Workaround


The system power supply must rise adequately so that the VDD core supply

powers up from 0V to 500mV within 1us across the operational range of
the application (i.e. including the hottest required power up condition).



RAM: Memory Controller RAM can lock up on slow power up of the VDD core supplyMUCts03702

Description

The memory controller RAM can lock up on a slow power up of the VDD core

supply such that no RAM access is possible. The condition is not
recoverable until the device is powered down and powered up again with a
faster VDD power up. This behavior is more evident at high temperature.

Workaround


The system power supply must rise adequately so that the VDD core supply

powers up from 0V to 500mV within 1us across the operational range of
the application (i.e. including the hottest required power up condition)



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

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.



FTM: Erroneous Erase Verify P-Flash Section range does not flag errorMUCts03724

Description

The memory controller Erase Verify P-Flash Section command verifies that

a given P-Flash address range is erased. It checks a number of phrases
from a start address. The range is only valid within a 256 Kbyte block
boundary and an ACCERR should be generated in the case that the range
crosses a 256 Kbyte address boundary. This would be an invalid command
setup by the user.

However, this does not happen. Providing too large a number of phrases
so that the end address is in a different 256 Kbyte block will result in
an incorrect bound being setup, possibly lower than the starting
address. No error flag is set.

This will lead the verify command to fail if it hits a programmed
location outside of the intended range.

Workaround


Ensure that the parameters for the Erase Verify P-Flash Section command

limit the verify operation to within a 256 Kbyte aligned address block
(as specified for the command).



FTM RD1ALL command uses incorrect margin level to verify Data Flash IFRMUCts03725

Description

The RD1ALL command verifies the main array for the Data Flash and

Program Flash using the correct customer level but verifies the Data
Flash useing the more strigent NXP margin level to verify the Data
Flash IFR.

Since the ERSALL command verifies all memory to the stringent NXP
level this is not considered an issue unless an extremly long time
between ERSALL and RD1ALL has occured.

Workaround


Use RD1ALL as normal, should pass correctly unless an extreme length of

time since the ERSALL has elapsed.



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

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 resultMUCts03796

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.



FTM: EEPROM Emulation corruption on consecutive resets MUCts03852

Description

If the EEPROM Emulation flow is reset (or powered down) during the 

programming or copying of data records in a data clean–up cycle
(periodically caused by programming of an EEE data record to the D-
flash) and a successive Enable EEPROM Emulation command is also
interrupted by a reset (or power down) then the EEPROM Emulation record
system can become corrupted.

This will be flagged following the second reset by the ACCERR, MGSTAT1
& MGSTAT0 bits in the FSTAT register being set.

This condition is not recoverable without re-partitioning the D-flash.


Workaround


Ensuring the following will minimize susceptibility to this scenario -

a) that all EEPROM Emulation activity has completed (by checking
ETAG = 0 and the MGBUSY flag in FSTAT is cleared) before the module
powers down or generates any controlled reset.
b) that any other system resets that might occur during EEE programming
activity are kept to a minimum.




FTM: EEPROM Emulation Erroneous Dead SectorsMUCts03853

Description

If the EEPROM Emulation flow is reset (or powered down) within a 20us 

window at the beginning of the programming of an EEE data record to the
D-flash, this can cause the EEPROM Emulation to erroneously drop a
sector from the flow as a dead sector.

This error condition is managed correctly by the Emulated EEPROM flow
and flagged by the setting of the PGMERIF flag in the FERSTAT register.
This does not affect the EEPROM Emulation data or operation, however in
the case that this occurs several times the maximum number of dead
sectors will be reached and a critical EEPROM Emulation error flagged
by the setting of the ERSVIF0 flag in the FERSTAT register.

Workaround


Ensuring the following will minimize susceptibility to this scenario -

a) that all EEPROM Emulation activity has completed (by checking
ETAG = 0 and the MGBUSY flag in FSTAT is cleared) before the module
powers down or generates any controlled reset.
b) that any other system resets that might occur during EEE programming
activity are kept to a minimum.




FTM: EEPROM Emulation corruption on consecutive Enable EEPROM Emulation CommandsMUCts03854

Description

If the EEPROM Emulation flow is reset (or powered down) during a data 

clean–up cycle (periodically caused by programming of an EEE data
record to the D-flash) then if, following the reset, the Enable EEPROM
Emulation command is executed twice by the application flow the EEPROM
Emulation records system can become corrupted on the second enable.
If the Enable EEPROM Emulation command is used only once during program
execution after reset there is no issue.

The error condition will be flagged by the second Enable EEPROM
Emulation command setting the ERSVIF0 flag followed shortly by the
SFDIF and DFDIF flags in the FERSTAT register.

Following any further resets this condition will also be flagged by the
ACCERR, MGSTAT1 & MGSTAT0 bits in the FSTAT register being set.

This condition is not recoverable without re-partitioning the D-flash.

Workaround


Only execute the Enable Emulated EEPROM command once in the application 

flow.

Ensuring the following will minimize susceptibility to this scenario -
a) that all EEPROM Emulation activity has completed (by checking
ETAG = 0 and the MGBUSY flag in FSTAT is cleared) before the module
powers down or generates any controlled reset.
b) that any other system resets that might occur during EEE programming
activity are kept to a minimum.




FTM: Version ID qualifier for FTM errata MUCts03859

Description

This entry provides information with regard to patches applied in 

relation to three preceding FTM errata.

Details relating to the Version ID can be found in the device Data Book
in section "1.7 Part ID Assignment".

The following errata are not valid for devices with Version ID = 0x0001
MUCts03821
MUCts03822
MUCts03823

Workaround


N/A 




CPU: Breakpoint missed at simultaneous taghitsMUCts03867

Description

The CPU execution priority encoder evaluates taghits and then 

generates a breakpoint if a taghit must lead to an immediate
breakpoint as determined by the DBG module.

If the DBG module indicates that this taghit leads to an immediate
breakpoint then the CPU loads the execution stage with SWI or BGND thus
generating the breakpoint.

At simultaneous taghits the lowest channel has priority.
If taghits on 2 channels simultaneously, whereby the lower channel tag
must be ignored, but the higher channel tag must cause a breakpoint,
then the breakpoint request is erroneously missed.
Thus if channel[1:0] taghits occur simultaneously whereby channel[0]
must be ignored but channel[1] must cause a breakpoint, then the
breakpoint request on channel[1] is erroneously missed and no
breakpoint generated.

The DBG module recognises the taghit and the state sequencer
transitions accordingly. Furthermore the taghit causes the DBG module
to request a forced breakpoint, which means that a late CPU breakpoint
occurs. If the tagged instruction is a single cycle instruction, the
breakpoint occurs at the second instruction following the tagged
instruction.
Otherwise the breakpoint occurs at the instruction immediately
following the tagged instruction.

This bug requires that separate tags are placed on the same
instruction. This is not a typical case when using exact tag addresses.
It is more relevant in debugging environments using range modes, where
tags may cover a whole range. In this case a tagged range may cover a
tag or another tagged range, making simultaneous taghits possible.

This is a debugging issue only.

Workaround


Do not attach multiple tags to the same exact address. 

When attaching multiple tags to the same address by overlapping tag
ranges in range modes, or covering a tag with a tag range in range
modes, then the missed tag can be avoided by mapping the final state
change to the lower channel number.

For example the case
Channel[0] tags a range; channel[3] tags an instruction within that
range.
From DBG State1 Taghit[0] leads to State2. (DBGSCR1=$6)
From DBG State2 Taghit[3] leads to FinalState.(DBGSCR2=$5)
In State2 a simultaneous Taghit[3,0] scenario would miss the breakpoint.

This can be avoided by using the alternative DBG configuration
Channel[2] tags a range; channel[0] tags an instruction within that
range.
From DBG State1 Taghit[2] leads to State2. (DBGSCR1=$3)
From DBG State2 Taghit[0] leads to FinalState.(DBGSCR2=$7)



BDM: Incomplete Memory Access on misaligned access due to BDM featuresMUCts03934

Description

If a misaligned word write access is directly followed by an attempted

entry into active BDM, then the second byte access may be performed on a
different target due to the memory map switching for BDM active.

Depending on the type of access this can lead to the following situations...
1. When writing in the address range from $7F_FEFF to $7F_FFFD in the
external space the MMC splits the accesses into two 8-bit accesses. It
is able to complete the first access, but just before the second access
the BDM firmware becomes mapped into this address location and the
second byte access goes to the firmware.
This can only occur if the last cycle of the access instruction is a
word write to an odd address AND the instruction is followed by BGND or
a tagged breakpoint.

This can only occur on devices featuring an External Bus Interface.

2. On a misaligned word write with a global store (GSTD,GSTS,GSTX,GSTY)
in the address range $XX_0FFF to $XX_3FFD, the first split access is
performed correctly in the external space, but in the second byte cycle
the MMC is instructed to interpret the address coming from the CPU as a
local address, which is the internal RAM. Since accesses to the RAM are
not split, the MMC enters an inconsistent state and never acknowledges
the CPU access. This causes the CPU flow to cease.
This can only occur if the CPU executes a global store instruction which
writes to an odd address in the last instruction cycle AND the
instruction is followed by BGND or a tagged breakpoint.

This can only occur on devices featuring an External Bus Interface.

3. Generally on a misaligned global store (GSTD,GSTS,GSTX,GSTY) the
lower 16-bits of the global address are interpreted as a local address
for the second byte access. This can result result in unintended
accesses to registers or external RAM.







Workaround


Do not set breakpoints or insert BGND after a GSTD.


Remove all instances of BGND from code when not debugging.








FTM: EEE Brownout handling MUCts03984

Description

There is an issue in the case of a reset occurring at specific 

points during EEE programming or erase activities of the D-Flash (in
this context referred to as an EEE brownout).

This issue may manifest in different ways:

Creation of an erroneous Dead sector:-
- this will be reported by the error flags
- more than 24 occurrence of Dead sectors will lead to an EEE Format
error reported by the FERSTAT flags

An EEE Format error:-
- This is reported immediately by the first Enable EEE command
following reset or later by FERSTAT flags during the normal flow of
the EEE

Data corruption of EEE RAM locations:-
- of EEE RAM locations having no associated record in the D-flash
- In very rare cases corruption of EEE RAM locations having associated
records in the D-flash

This behavior is limited only to EEE brownouts which occur at specific
points during EEE programming or erase activities. The vast majority of
EEE brownouts will be resolved correctly.

In a stable design which allows the EEE to halt activities before the
power supply is disabled, such brownouts are considered rare.




Workaround


While it is not possible to avoid the error occurring, it is possible

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

An applications should always monitor the Error flags following reset
and when launching the EEE enable command. On detecting a format error
launch a Disable EEE command to halt any pending EEE activity. Data can
be read and written to the EEE RAM but EEE programming should not be
enabled.

Enable the EEE error interrupt to be informed of a format error or
generation of a Dead sector. For less than 24 Dead sectors the EEE will
continue to work. If reached a format error will be generated. The
Dead sector level can be checked periodically by an application using
the Query EEE command.

Data corruption could be checked for by implementing CRC checks on the
data in the EEE RAM.

Ensuring the following will minimize susceptibility to this scenario -
a) that all EEPROM Emulation activity has completed (by checking ETAG =
0 and the MGBUSY flag in FSTAT is cleared) before the module powers
down or generates any controlled reset.
b) that any other system resets that might occur during EEE programming
activity are kept to a minimum.





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

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 */



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.







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

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.