NXP® SemiconductorsMSE9S12NE64_0L19S
Mask Set ErrataRev. April 17, 2012



MC9S12NE64, Mask 0L19S


Introduction
This errata sheet applies to the following devices:

MC9S12NE64



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
MUCts01084 S12_dbg DBG: BDM firmware code execution may erroneously cause forced trigger YES
MUCts01158 ephy EPHY- Active LED does not turn on while PHY is transmitting or receiving YES
MUCts01160 ephy PHY_VDDRX draws up to 2mA of current when EPHY is dasabled. NO
MUCts01162 ephy EPHY - UNH Test #14.3.6.a: Link Fail Effect on the Receive Functions. YES
MUCts01164 ephy EPHY formed 10Base-T link when less than "lc_max NLPs" received. YES
MUCts01172 ephy EPHY: MDIO write requires 3 MDC clocks to complete transaction YES
MUCts01454 ephy EPHY - NOT accepting valid LTP when greater than 100 ns NO
MUCts01493 S12_cpu Tagged breakpoints missed if tag attach and interrupt are simultaneous NO
MUCts01967 S12_bdm Possible manipulation of return address when exiting BDM active mode YES
MUCts02415 S12_mebi MEBI: Missing ECLK edge on first external access after mode switching YES
MUCts03403 spi SPI: Disabling slave SPI together with clearing CPHA while SS low locks transmit shift register for the next transmission YES
MUCts03468 atd_10b8c ATD: Abort of an A/D conversion sequence with write to ATDxCTL0/1/2/3 may not work YES
MUCts03527 fts64k FTS64K: Blind Spot in Data Compress Command Algorithm YES
MUCts03685 atd_10b8c ADC: conversion does not start with 2 consecutive writes to ATDCTL5 YES
MUCts03793 S12_mmc S12_mmc: /XCS is erroneously asserted on accesses to internal BDM resources NO
MUCts04163 tim_16b4c TIM_16B4C: Output compare pulse is inaccurate YES
MUCts04247 sci SCI: RXEDGIF occurs more times than expected in IR mode YES



DBG: BDM firmware code execution may erroneously cause forced triggerMUCts01084

Description

Breakpoints are temporarily disabled while the MCU is executing BDM

firmware code when operating in active BDM mode. It logically follows
that debug module triggers are disabled in the same manner. While tagged
triggers are disabled, forced triggers are not and therefore may cause
the debug module to trigger erroneously.

In most circumstances this will only be a problem in outside range
trigger mode. In order to see an erroneous trigger in another trigger
mode, a forced trigger must be configured in the BDM firmware address
range ($FF00-$FF80) and an exact address bus match must occur. This
memory area would typically contain interrupts, vectors or program code,
and would therefore be a very unlikely location for the configuration of
a forced trigger address.

Workaround


Outside range trigger mode should not be used when configuring forced

triggers if the trigger range contains the memory area where the BDM
firmware code resides ($FF00-$FF80) and the user intends to operate the
MCU in active BDM mode.



EPHY- Active LED does not turn on while PHY is transmitting or receivingMUCts01158

Description

When the EPHY is enabled and is transmitting or receiving data the

active LED(ACTLED) will not turn on when the LEDEN bit is set to a one.

Workaround


The LED pin can be controlled via software.


The RXACT and TXACT bits in the EMAC RXCTS and TXCTS registers can be
monitored for transmitter and receiver activity.



PHY_VDDRX draws up to 2mA of current when EPHY is dasabled.MUCts01160

Description

The PHY_VDDRX power supply draws up to 2mA of current when the EPHY is

disabled. This additional current is present in all operating modes
including STOP mode.

Workaround


None.



EPHY - UNH Test #14.3.6.a: Link Fail Effect on the Receive Functions.MUCts01162

Description

The EPHY sometimes passes the 1st frame of of valid data to MAC when in

the Link Test Fail State and should not do so.

For a signal to be accepted, there needs to be a link present between
the two stations. A link is recognized by the reception of link test
pulses or data on a stations RD circuit, else the station enters the
Link Test Fail state. When in this state, a valid packet sent to the RD
circuit shall not be accepted, but shall cause the station to enter the
Link Test Pass state. Thus, a packet immediately following the first
packet shall then be accepted. An important exception to this is if the
device performs auto-negotiation. As referenced in section 28.2.2.2 and
figure 28-17, an auto-negotiating device will not transition to the Link
Test Pass state when receiving 10BASE-T data.

Workaround


1st frame of of valid data to should be filtered by the software stack. 




EPHY formed 10Base-T link when less than "lc_max NLPs" received.MUCts01164

Description

New UNH test Last Modification on April 23, 2003.

EPHY formed 10Base-T link when less than "lc_max NLPs" received.

A connection was establish(not a link) to the EPHY. A Traffic Generator
then sent the DUT less than lc_max link pulses spaced at 16 ms followed
by validly formed 10BASE-T frames spaced at 16 ms. The EPHY formed
10Base-T link.

Workaround


1. The Auto-Negotiation feature can be by passed if the line speed is known.


2. Auto negotiation can be restarted if an improper link has been formed.



EPHY: MDIO write requires 3 MDC clocks to complete transactionMUCts01172

Description

At the end of a write cycle 3 additional MDC clocks must be supplied

before the completion of the transaction.

Workaround


Follow a MDIO write with an MDIO read of any MDIO register. 




EPHY - NOT accepting valid LTP when greater than 100 nsMUCts01454

Description

If a link partner's LTP is greater than 100 ns, using auto-negotiation,

then the EPHY does not recognize it. This results in a failure to
auto-negotiate.

Workaround


Disable Auto-negotiation and configure the EPHY to operate in 100TX or

10BaseT mode.



Tagged breakpoints missed if tag attach and interrupt are simultaneous MUCts01493

Description

The errata concerns the DBG-CPU interface in DBG mode whilst configured

for tagging. If an interrupt occurs at the moment that a tag is attached
to an opcode being loaded into the instruction queue, the flag will get
set, but the part may not enter active BDM mode.

Using the DBG configuration BDM=DBGBRK=1, BEGIN=0, an event causing a
flag to be set should cause a break to BDM. The flag gets set, but the
part does not enter active BDM mode. The CPU executes the interrupt
service routine, instead, and returns to the correct position in the
program flow, but the breakpoint to BDM is missed.

The problem does not occur if the DBG module is configured for operation
in BKP mode (BKABEN=1). This is because, even if the flag bit is set,
the BKABEN bit is not cleared. On returning from the interrupt service
routine, the tag is re-applied when the PC is fetched after the
interrupt service routine, and the part enters BDM after the interrupt
service routine. In BKP mode with TRGSEL=0, no flags are set when a
taghit occurs.

In BKP mode with TRGSEL=1, the flag is also set erroneously on entering
the interrupt service routine. However, it is unlikely that a user would
be affected by the flag being set early (unless the service routine were
exceptionally long), due to the length of time needed to read out the
DBGSR (flag bits) over the BKGD pin; typically, during this time, the
part would enter active BDM when the tag is re-applied.

Workaround


None.



Possible manipulation of return address when exiting BDM active modeMUCts01967

Description

Upon leaving BDM active mode, the CPU return address is stored

temporarily for a few cycles in the BDM shift register. If a BDM command
transmission is detected during this time, the return address will be
manipulated in the BDM shift register. This situation is likely to occur
when a CPU BGND instruction is executed in user code during debugging
under the following conditions:

(i) The BDM module is not enabled AND
(ii) BDM commands are sent from the host

If this situation occurs, the CPU will execute BDM firmware and will
check the status of the ENBDM bit in the BDMSTS register. If the BDM is
disabled, the ENBDM bit will be clear, and hence the BDM firmware will
be exited and the shift register manipulation described above will occur.

Workaround


Avoid using the BGND instruction when the ENBDM bit in the BDMSTS

register is cleared.



MEBI: Missing ECLK edge on first external access after mode switchingMUCts02415

Description

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

external access is lost after switching from a single chip mode with
enabled ECLK output to an expanded mode. The ECLK is erroneously held in
the high phase thus the first external bus access does not generate a
rising ECLK edge for the external logic to latch the address. The ECLK
stretches low after the lost access resulting in all following external
accesses to be valid.

Workaround


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

after switching the mode before executing the first external access.



SPI: Disabling slave SPI together with clearing CPHA while SS low locks transmit shift register for the next transmissionMUCts03403

Description

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

the SPI) together with clearing the CPHA bit while the SS pin is low
causes the transmit shift register to be locked for the next
transmission following the SPI being re-enabled as a slave with SS
still being low.

This means new transmit data is not accepted for the first
transmission after re-enabling the SPI (indicated by SPTEF staying low
after storing transmit data into SPIDR), but for the next following
transmission.



Workaround


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




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

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






FTS64K: Blind Spot in Data Compress Command AlgorithmMUCts03527

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.



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

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



S12_mmc: /XCS is erroneously asserted on accesses to internal BDM resourcesMUCts03793

Description

When writing or reading the internal BDM resources (address range $FF00

to $FFFF) via BDM hardware commands, the /XCS Chip Select signal is
erroneously driven low during the BDM access.

The /XCS signal is also driven low for CPU accesses performed to execute
BDM firmware when the CPU is in BDM active mode (BDMACT=1). This
includes the specific read/write cycle of the BDM firmware commands
READ_NEXT and WRITE_NEXT to access the targeted address of BDM firmware.

The R/W signal remains in read state in all these cases. The data
received by the above false external read accesses are discarded by the MCU.


Workaround


None. 




TIM_16B4C: Output compare pulse is inaccurateMUCts04163

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 1.1 (06 

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.









SCI: RXEDGIF occurs more times than expected in IR modeMUCts04247

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.