NXP® SemiconductorsMSE9S12XDG128_2M42E
Mask Set ErrataRev. April 17, 2012



MC9S12XDG128, Mask 2M42E


Introduction
This errata sheet applies to the following devices:

MC9S12XDG128, MC9S12XD128, MC9S12XA128, MC9S12XB128



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
MUCts03017 ect_16b8c ECT: TCNT counter resets in Input Capture Mode YES
MUCts03018 ect_16b8c ECT: CxF flag clears following a read to TCx on an OC event with TFFCA=1 YES
MUCts03019 ect_16b8c ECT: CxF flag clears following a wite to TCx on an IC event with TFFCA=1 YES
MUCts03037 ect_16b8c ECT: Forced OC on PT7 occured even when TIOS7 = 0 NO
MUCts03039 ect_16b8c ECT:Faulty OC event with OM/OL=0, OC7Mx=1, TIOSx=1 YES
MUCts03267 s12x_cpu S12X_CPU : CALL Instruction, wrong PC relative addressing YES
MUCts03301 s12x_cpu S12X_CPU: CPU ignores tag hit NO
MUCts03315 s12x_dbg DBG writing to DBGMFR corrupts DBGSCR3 YES
MUCts03316 s12x_dbg DBG outside range mode databus qualification ignored YES
MUCts03320 s12x_dbg DBG Range Mode TAGB and TAGD influence in range modes YES
MUCts03337 s12x_cpu DBG Wrong trace buffer entries during stretched bus cycles NO
MUCts03390 atd_10b16c ATD: Abort of an A/D conversion sequence with write to ATDxCTL0/1/2/3 may not work YES
MUCts03521 ftx_128k1 FTX: Blind Spot in Data Compress Command Algorithm YES
MUCts03564 mscan MSCAN: Corrupt ID may be sent in early-SOF condition YES
MUCts03618 s12x_dbg DBG No address match if next transaction is misaligned word access YES
MUCts03619 s12x_dbg DBG Pure PC mode too many trace buffer entries NO
MUCts03635 eetx_2k eetx2k An interrupt following immediately after execution of a STOP instruction may disable read access to the EEPROM array YES
MUCts03653 vreg_3v3 vreg_3v3.05.02: Possible incorrect operation if device is wakened from stop mode within 4.7µs of stop mode entry NO
MUCts03689 atd_10b16c ADC: conversion does not start with 2 consecutive writes to ATDCTL5 YES
MUCts03758 s12x_dbg DBG: State flags and counter corrupted by simultaneous arm and disarm YES
MUCts03869 s12x_cpu CPU: Breakpoint missed at simultaneous taghits YES
MUCts03951 s12x_bdm BDM: Incomplete Memory Access on misaligned access due to BDM features YES
MUCts03977 pwm_8b8c PWM: Emergency shutdown input can be overruled YES
MUCts04040 ftx_128k1 FTX_128k1 : An interrupt occurring at the end of execution of a STOP instruction may cause an erroneous interrupt vector to be taken YES
MUCts04080 pim_9xd_g128 PIM: Edge-sensitive mode of IRQ-pin may cause incorrect interrupt vector fetch YES
MUCts04095 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
MUCts04155 ect_16b8c ECT_16B8C: Output compare pulse is inaccurate YES
MUCts04165 ftx_128k1 Flash: Burst programming issue if bus clock frequency is higher than oscillator clock frequency YES
MUCts04244 sci SCI: RXEDGIF occurs more times than expected in IR mode YES



ECT: TCNT counter resets in Input Capture ModeMUCts03017

Description

Normal Operation:


Timer Free Running Counter, also called as Timer Counter resets to
0x0000 on a Channel 7 Output Compare event when Timer Counter Reset
Enable (TCRE) bit of TSCR2 registers is set to 1. This assumes that
TIOS7 bit of TIOS register is set to a 1 (Output Compare mode).

Issue: Erroneously this behaviour was found to occur even when
TIOS7 bit of TIOS register was set to a "0" (Input Capture mode)

Workaround


Reseting Free Running Counter alias Timer Counter can be avoided by

setting Timer Counter Reset Enable (TCRE) bit of TSCR2 register to a "0".



ECT: CxF flag clears following a read to TCx on an OC event with TFFCA=1MUCts03018

Description

Problem:

Normal Operation:
With TIOS = 1 (Output Compare mode) and TFFCA = 1 (Fast Flag Clearing
mechanism) a write to TCx register following an output compare event
clears the flag.

Erroneous Operation:
A read to TCx register following an Output Compare event clears Cxf flag
in TFLG1 register.

Workaround


Customer should avoid reading TCx register following an Ouput Compare event. 




ECT: CxF flag clears following a wite to TCx on an IC event with TFFCA=1MUCts03019

Description

Normal Operation: 

With TIOS = 0 (Input Capture (IC) mode) and TFFCA = 1 (Fast Flag
Clearing mechanism) a read to TCx register following an Input Capture
(IC) event clears CxF (flag) bit of TFLG1 register.

Erroneous Operation:
A write to TCx register following an Input Capture (IC) event clears Cxf
(flag) bit of TFLG1 register.

Workaround


Customer should avoid writing to TCx register following an Input Capture

(IC) event.



ECT: Forced OC on PT7 occured even when TIOS7 = 0MUCts03037

Description

Correct Operation:


Forced Output Compare (OC) operation on channel 7 requires TIOS7 bit be
set to a “1” for a successful Ouput Compare (OC) event.

Faulty Operation:

Forced Ouput Compare (OC) action was noticed on Channel 7 inspite of
TIOS7 being set to a “0”.

Workaround


None. 




ECT:Faulty OC event with OM/OL=0, OC7Mx=1, TIOSx=1MUCts03039

Description

Correct Operation:


When timer is enabled (TEN bit of TSCR1 register is set to 1) and Output
Compare functionality is selected (TIOSx bit of TIOS register is set) on
a match (TCNT = Tcx) an output compare event(dictated by OM/OL bits of
TCTL1/TCTL2 register) is generated. Please not that the Output Compare
is registered internally.

Faulty Operation:

Consider a case, when an normal Output Compare event (driving port to 1)
was performed. You intend to dis-connect output compare logic from pin
logic. Hence you configure (OM/OL bits to a “0”), but your TIOSx bit is
still set to a “1”. Also, you intend to use masking feature of output
compare so you set TIOS7=1 and you have OC7Mx bit set to a “1”. If the
next output compare match(TCNT = Tcx) happens to be normal output
compare event, the default state of internal register (0) was noticed on
the channel.

In reality the output port should not have toggled since OM/OL were set
to 0.
This is an erroneous behaviour.

Workaround


Make sure that OC7Mx bit is set to "0" if not using OC7M feature for

that channel. If using masking feature, please remember to set OC7Mx bit
to "0" as soon as you have a channel 7 Compare event.



S12X_CPU : CALL Instruction, wrong PC relative addressingMUCts03267

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.



S12X_CPU: CPU ignores tag hitMUCts03301

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. 




DBG writing to DBGMFR corrupts DBGSCR3 MUCts03315

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 ignoredMUCts03316

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 modesMUCts03320

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



DBG Wrong trace buffer entries during stretched bus cyclesMUCts03337

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 and simultaneous XGATE
PRR access during trace capture.

Workaround


None. 




ATD: Abort of an A/D conversion sequence with write to ATDxCTL0/1/2/3 may not workMUCts03390

Description

Starting a conversion with a write to ATDxCTL5 or on an external trigger

event, and aborting immediately afterwards with a write to ATDxCTL0,
ATDCTL1, ATDxCTL2 or ATDxCTL3 can fail to stop the conversion process.

Workaround


Only write to ATDxCTL4 to abort an ongoing conversion sequence.


Use the recommended start and abort procedures from the Block Guide.
Section : Initialization/Application Information
Subsection: Setting up and starting an A/D conversion
Subsection: Aborting an A/D conversion



FTX: Blind Spot in Data Compress Command AlgorithmMUCts03521

Description

If the range of Flash addresses to be compressed is 32K or greater, the

data at one of the addresses will be effectively ignored. The address
affected is 32K from the upper address read in the data compress
algorithm, e.g., for an address range of 32K, the first data read in the
algorithm will not affect the final signature provided by the algorithm.


Workaround


Limit range of addresses to be compressed to less than 32K addresses.

Execute multiple data compress commands to compress larger Flash address
ranges.



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

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]}



DBG No address match if next transaction is misaligned word accessMUCts03618

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 entriesMUCts03619

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. 




eetx2k An interrupt following immediately after execution of a STOP instruction may disable read access to the EEPROM arrayMUCts03635

Description

An interrupt request immediately following execution of a STOP 

instruction may cause the EEPROM array to return incorrect data when
read. The problem will only occur if all of the following conditions
are met:

1) S bit in the CCR register is cleared (stop mode enabled)
2) I bit in the CCR register is cleared (interrupts enabled)
3) A STOP instruction is executed by the microcontroller
4) An interrupt becomes pending between 0 and 0.5 bus clock cycles
after beginning of the STOP instruction execution.

In this case the microcontroller will wake-up correctly from the stop
mode, but the EEPROM array will return incorrect data when a read
operation is performed.

Access (read or write) to any of the EEPROM registers or write into the
EEPROM array (to start a command sequence) will restore the read
access. The EEPROM will return the correct data afterwards.

Workaround


If the STOP instruction is executed while interrupts are enabled,

read or write any of the EEPROM registers after wake-up from stop mode
to ensure correct operation. Alternatively a write into the EEPROM
array (as part of a command sequence) can be performed instead of the
register access.



vreg_3v3.05.02: Possible incorrect operation if device is wakened from stop mode within 4.7µs of stop mode entryMUCts03653

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 is powered by the on-chip voltage regulator.
2) Device enters stop or pseudo-stop mode (see Stop mode entry
description below)
3) The wake-up signal is activated within a specific and 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 narrow width of the susceptible window 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 (provided the CPU is in stop or pseudo-stop
mode)

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. Software
written to deal with valid Low Voltage Resets should be implemented to
correctly manage erroneous LVR events.

It is 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.



ADC: conversion does not start with 2 consecutive writes to ATDCTL5MUCts03689

Description

When the ATD is started with write to ATDCTL5

and, which is very unusual and not necessary,
within a certain period again started with write
to ATDCTL5. The conversion will not start at all.
This does only happen if the two consecutive writes to ATDCTL5 occur
within one "ATD clock period". An ATD clock period is defined by a full
rollover of the ATD clock prescaler. That is for example PRS[4:0] = 2 -
> (2+1)*2 = within 6 bus cycles.


Workaround


Only write once to ATDCTL5 when starting a conversion.


Use the recommended start and abort procedures from the Block Guide.
Section : Initialization/Application Information Subsection: Setting up
and starting an A/D conversion Subsection: Aborting an A/D conversion



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

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.



CPU: Breakpoint missed at simultaneous taghitsMUCts03869

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 featuresMUCts03951

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 active BDM.

Thus 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 in unintended accesses to
registers.












Workaround


Avoid setting breakpoints after a GSTD.


When not debugging, remove all instances of BGND from code.









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.




FTX_128k1 : An interrupt occurring at the end of execution of a STOP instruction may cause an erroneous interrupt vector to be takenMUCts04040

Description

An active interrupt request at the end of execution of a STOP 

instruction may cause the Flash array to return an incorrect interrupt
handler address. The problem will only occur if all of the following
conditions are met:

1) S bit in the CCR register is cleared (stop mode enabled)
2) I bit in the CCR register is cleared (interrupts enabled)
3) A STOP instruction is executed by the microcontroller
4) An interrupt becomes pending during a one bus clock cycle window at
the end of the STOP instruction execution.

In this case the microcontroller will wake-up from the stop mode as
requested by the interrupt request but the Flash module will return the
last entry read into the instruction pre-fetch queue as the address of
the interrupt handler. The CPU will therefore jump execution to an
unintended location.

The address vectored to will be defined by the contents of the Flash
following on from the stop instruction as shown below.

Where stop is at an even address -

-0002: 10EF // CLI
0000: 183E // STOP
0002: xxxx
0004: xxxx
0006: HHHH // HHHH taken as ISR handler address

Where stop is at an odd address -

-0002: xx10 // CLI
0000: EF18 // CLI / STOP
0002: 3Exx // STOP
0004: xxxx
0006: HHHH // HHHH taken as ISR handler address

The vector is an effective jump to execute code from the local 64K
memory map. In the case that an erroneous vector is taken then
(depending on the location vectored to) this will result in out of
sequence execution of code, execution from non-code region of memory or
execution of misaligned code and will typically lead to a COP watchdog
timeout or an illegal access reset.

Workaround


1) A software solution is possible by ensuring that the appropriate 

memory location following the stop instruction contains a valid dummy
vector pointing to an appropriate ISR routine terminated with an RTI op-
code.

Where there is more than one possible source enabled that might
generate an interrupt during stop entry (e.g. RTI + key-wake) then the
dummy vector should point directly to an RTI op-code ¡V once the RTI has
been executed then the pending interrupt that generated the wake from
stop will then be serviced appropriately.

A local dummy RTI can be programmed, e.g.

-0002: 10EF // CLI
0000: 183E // STOP
0001: 0A // RTC or other change of flow command
0002: 0B // DUMMYH RTI
0004: xxxx // don't care
0006: HHHH // DC.W DUMMYH ƒ¬---- taken as handler address
(HHHH denotes the absolute address of the RTI
Instruction above)

This shows moving the stop entry instructions to the end of a (possibly
separate stop entry function) so that the RTI and dummy vector are
prevented from being executed under normal operation by the RTC (or
other change of flow instruction).

Or alternatively the dummy RTI op-code might be created as a global
constant and its address stored at the dummy vector location.

A code example of this using the CodeWarrior® tools is shown below.

2) Where there is only a single interrupt source enabled then stop is
to be executed, then a variation of the workaround above is possible
where the HHHH value is programmed with the address of the intended
wake-up interrupt service handler (i.e. the same address as in the
interrupt vector table). In this case, after the stop instruction the
wake-up interrupt will vector to the expected service routine as
intended.

To avoid on chip peripheral generating a pending interrupt during the
stop execution (for example one of the on chip timers) local peripheral
interrupt masks should be set for any active interrupt sources prior to
execution of the stop instruction.

3) Where the only interrupt source enabled is an on chip timer (RTI or
API) then it is possible to avoid the errata condition 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 will not occur during Stop/Pseudo-Stop entry.


4) Support is provided on the MCU for managing the following system
conditions:
* COP watchdog reset
* Ilegal 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.

5) The typical practice of filling all unused Flash and RAM space with
the op-code for the SWI instruction can result in the location being
vectored to generating an SWI exception. SWI exception routine should
be written in this case to manage this event.

Code example (Code Warriro)

Create a global constant in non-banked memory to implement the RTI code

#pragma CONST_SEG __NEAR_SEG ROM_VAR /* non banked segment */
unsigned char __near const var_rti = 0x0B; /* opcode for RTI (0x0B)*/

And either in non-banked memory:

#pragma CODE_SEG __NEAR_SEG STOP_CODE /* must start on even address */

Or in banked memory:

#pragma CODE_SEG __FAR_SEG IN_PAGED_ROM_ALIGNED /* must use ALIGN 2 */

Create a separate routine to execute the CLI/STOP instruction
combination

void GoToStop() {
__asm {
CLI /* ANDCC #0xEF */
STOP
BRA *+6; /* jump past dummy vector */
SWI
SWI
DC.W var_rti
}
}

The GoToStop() routine must be placed in a specific memory segment so
that it starts at an even address; either into a dedicated segment
starting at an even address
e.g.
SEGMENTS
STOP_ROM = READ_ONLY 0x7FF4 TO 0x7FFF;
PLACEMENT
STOP_CODE INTO STOP_ROM;

or into a segment defined with an ALIGN 2 modifier (which will
automatically place it onto an even address)
e.g.
SEGMENTS
PAGE_FC = READ_ONLY 0xFC8000 TO 0xFCBFFF ALIGN 2;
PLACEMENT
IN_PAGED_ROM_ALIGNED INTO PAGE_FC ;



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

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=1 MUCts04095

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 inaccurateMUCts04155

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 02.05 (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.







Flash: Burst programming issue if bus clock frequency is higher than oscillator clock frequencyMUCts04165

Description

If S12X is running at a bus clock frequency higher than the oscillator

clock frequency (Fbus > Fosc), flash words may remain not programmed
after a program burst sequence. Software methods can be used to avoid
this problem. If burst programming is not used, no errors occur.

The root cause of this issue is related to flash internal state machine
which needs about 2 to 3 oscillator clock periods to be ready to accept
a new flash command after the assertion of the CBEIF flag.

Note that this latency of flash state machine is related to the
assertion of CBEIF and the start of a new command sequence (i.e. a write
to a flash word). There is no latency after the assertion of the CCIF flag.



Workaround


Adding a time delay between the check of CBEIF flag and the start of the

next flash program command sequence will ensure that all words will be
programmed. Add a delay of (3 * (Fbus/Fosc)) Bus clock cycles after
CBEIF is set, that can be achieved by the addition of NOPs (one NOP
instruction takes one bus cycle to execute).

Note that since a flash word program operation takes much longer than 3
oscillator clock periods, there is no impact in the total programming
time of a long program burst sequence by adding a delay of 3 clocks.

The example below illustrates the proposed workaround:

Code below executes a program burst sequence by launching a new flash
program command right after the assertion of the CBEIF flag.


1 LDX #(PGM_ADDR_START+PGM_SIZE) ;Load X with last addr+1
2 STX TMP_VAR ;Store last programmed addr+1 at
tmp_w1 var
3 LDX #PGM_ADDR_START ;Load X with start addr
4
5 LOOPGM: ;Loop Program
6 BRCLR FSTAT, #$80, * ;Wait for buffer empty (CBEIF = 1)
7
8 ; -> Time delay of 3 Osc clock periods must be inserted at this point.
9
10 MOVW #DATA 2,X+ ;Write DATA to address pointed by
index X
11 MOVB #FCMD_PGM FCMD ;Write PGM command code to FCMD
register
12 MOVB #$80 FSTAT ;Launch command
13 CPX TMP_VAR
14 BLO LOOPGM

The minimum time delay for the code above can be found by the equation
below:

Time delay (in Bus clock cycles) = 3*(Fbus/Fosc) - (bus clock cycles
need by BRCLR at line 6) - (bus clock cycles needed by MOVW at line 10)

Considering that the BRCLR instruction at line 6 takes 3 bus clock
cycles after the assertion of the CBEIF and that the MOVW takes 3 bus
clock cycles to be executed, the equation above can be written as:

Time delay (in Bus clock cycles) = 3*(Fbus/Fosc) - 6

For the case of Fosc=4MHz and Fbus=12MHz, a time delay of
3*(12MHz/4MHz) - 6 = 3 bus clock periods is needed. So, at least 3 NOP
instructions must be inserted at line 8 for proper operation, in this
example.

Depending on the configuration of Bus clock frequency and oscillator
clock frequency, and due to the actual code used in the application, the
required time delay of 3 oscillator clock cycles may be already spent
inside of the programming routine and the problem will not be detected.
Under certain conditions described by the equations and explanation
above, adding NOPs may not be required.





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.