KINETIS_1N89E
Rev. 31 JAN 2014
Mask Set Errata for Mask 1N89E
This document contains errata information for Kinetis Mask Set
1N89E but excludes any information on certain security-related
modules.
A nondisclosure agreement (NDA) is required for any security-related
module information.
For more information on obtaining an NDA, please contact your local
Freescale sales representative.
© 2014 Freescale Semiconductor, Inc.
Freescale Semiconductor
Mask Set Errata
KINETIS_1N89E
Rev 31 JAN 2014
Mask Set Errata for Mask 1N89E
Introduction
This report applies to mask 1N89E for these products:
• KINETIS
Errata ID
6804
6990
6939
4588
5751
5706
4710
6484
6573
5499
4590
6665
6348
5130
5472
5952
7027
7028
6472
Errata Title
CJTAG: Performing a mode change from Standard Protocol to Advanced Protocol may reset the CJTAG.
CJTAG: possible incorrect TAP state machine advance during Check Packet
Core: Interrupted loads to SP can cause erroneous behavior
DMAMUX: When using PIT with "always enabled" request, DMA request does not deassert correctly
FTFx: Launching the Read 1's Section command (RD1SEC) on an entire flash block results in access
error (ACCER).
FTFx: MCU security is inadvertently enabled (secured) if a mass erase is executed when the flash blocks/
halves are swapped. This issue only affects applications that use the flash swap feature.
FTM: FTMx_PWMLOAD register does not support 8-/16-bit accesses
FTM: The process of clearing the FTMx_SC[TOF] bit does not work as expected under a certain condition
when the FTM counter reaches FTM_MOD value.
JTAG: JTAG TDO function on the PTA2 disables the pull resistor
MCG: A reset or interrupt request due to a PLL loss of lock (LOL) condition will not occur asynchronously
MCG: Transitioning from VLPS to VLPR low power modes while in BLPI clock mode is not supported.
Operating requirements: Limitation of the device operating range
PMC: Incorrect reset source indication when waking up from VLLS0 mode.
SAI: Under certain conditions, the CPU cannot reenter STOP mode via an asynchronous interrupt
wakeup event
SMC: Mode transition VLPR->VLLS0(POR disabled)->RUN, will cause POR & LVD.
SMC: Wakeup via the LLWU from LLS/VLLS to RUN to VLPR incorrectly triggers an immediate wakeup
from the next low power mode entry
UART: During ISO-7816 T=0 initial character detection invalid initial characters are stored in the RxFIFO
UART: During ISO-7816 initial character detection the parity, framing, and noise error flags can set
UART: ETU compensation needed for ISO-7816 wait time (WT) and block wait time (BWT)
Table continues on the next page...
© 2014 Freescale Semiconductor, Inc.
Errata ID
4647
7029
7090
7031
5704
7091
7092
5928
6933
Errata Title
UART: Flow control timing issue can result in loss of characters if FIFO is not enabled
UART: In ISO-7816 T=1 mode, CWT interrupts assert at both character and block boundaries
UART: In ISO-7816 mode, timer interrupts flags do not clear
UART: In single wire receive mode UART will attempt to transmit if data is written to UART_D
UART: TC bit in UARTx_S1 register is set before the last character is sent out in ISO7816 T=0 mode
UART: UART_S1[NF] and UART_S1[PE] can set erroneously while UART_S1[FE] is set
UART: UART_S1[TC] is not cleared by queuing a preamble or break character
USBOTG: USBx_USBTRC0[USBRESET] bit does not operate as expected in all cases
eDMA: Possible misbehavior of a preempted channel when using continuous link mode
e6804: CJTAG: Performing a mode change from Standard Protocol to Advanced
Protocol may reset the CJTAG.
Errata type:
Errata
Description:
In extremely rare conditions, when performing a mode change from Standard Protocol to
Advanced Protocol on the IEEE 1149.7 (Compact JTAG interface), the CJTAG may reset
itself. In this case, all internal CJTAG registers will be reset and the CJTAG will return to the
Standard Protocol mode.
Workaround:
If the CJTAG resets itself while attempting to change modes from Standard Protocol to
Advanced Protocol and Advanced Protocol cannot be enabled after several attempts, perform
future accesses in Standard Protocol mode and do not use the Advanced Protocol feature.
e6990: CJTAG: possible incorrect TAP state machine advance during Check Packet
Errata type:
Errata
Description:
While processing a Check Packet, the IEEE 1149.7 module (CJTAG) internally gates the TCK
clock to the CJTAG Test Access Port (TAP) controller in order to hold the TAP controller in the
Run-Test-Idle state until the Check Packet completes. A glitch on the internally gated TCK
could occur during the transition from the Preamble element to the first Body element of Check
Packet processing that would cause the CJTAG TAP controller to change states instead of
remaining held in Run-Test-Idle
If the CJTAG TAP controller changes states during the Check Packet due to the clock glitch,
the CJTAG will lose synchronization with the external tool, preventing further communication.
Workaround:
To prevent the possible loss of JTAG synchronization, when processing a Check Packet,
provide a logic 0 value on the TMS pin during the Preamble element to avoid a possible glitch
on the internally gated TCK clock.
e6939: Core: Interrupted loads to SP can cause erroneous behavior
Errata type:
Errata
Description:
ARM Errata 752770: Interrupted loads to SP can cause erroneous behavior
Affects: Cortex-M4, Cortex-M4F
Mask Set Errata for Mask 1N89E, Rev 31 JAN 2014
2
Freescale Semiconductor, Inc.
Fault Type: Programmer Category B
Fault Status: Present in: r0p0, r0p1 Open.
Description
If an interrupt occurs during the data-phase of a single word load to the stack-pointer (SP/
R13), erroneous behavior can occur. In all cases, returning from the interrupt will result in the
load instruction being executed an additional time. For all instructions performing an update to
the base register, the base register will be erroneously updated on each execution, resulting in
the stack-pointer being loaded from an incorrect memory location.
The affected instructions that can result in the load transaction being repeated are:
1) LDR SP,[Rn],#imm
2) LDR SP,[Rn,#imm]!
3) LDR SP,[Rn,#imm]
4) LDR SP,[Rn]
5) LDR SP,[Rn,Rm]
The affected instructions that can result in the stack-pointer being loaded from an incorrect
memory address are:
1) LDR SP,[Rn],#imm
2) LDR SP,[Rn,#imm]!
Conditions
1) An LDR is executed, with SP/R13 as the destination
2) The address for the LDR is successfully issued to the memory system
3) An interrupt is taken before the data has been returned and written to the stack-pointer.
Implications
Unless the load is being performed to Device or Strongly-Ordered memory, there should be no
implications from the repetition of the load. In the unlikely event that the load is being
performed to Device or Strongly-Ordered memory, the repeated read can result in the final
stack-pointer value being different than had only a single load been performed.
Interruption of the two write-back forms of the instruction can result in both the base register
value and final stack-pointer value being incorrect. This can result in apparent stack corruption
and subsequent unintended modification of memory.
Workaround:
Both issues may be worked around by replacing the direct load to the stack-pointer, with an
intermediate load to a general-purpose register followed by a move to the stack-pointer.
If repeated reads are acceptable, then the base-update issue may be worked around by
performing the stack pointer load without the base increment followed by a subsequent ADD or
SUB instruction to perform the appropriate update to the base register.
e4588: DMAMUX: When using PIT with "always enabled" request, DMA request does
not deassert correctly
Errata type:
Errata
Mask Set Errata for Mask 1N89E, Rev 31 JAN 2014
Freescale Semiconductor, Inc.
3
Description:
The PIT module is not assigned as a stand-alone DMA request source in the DMA request
mux. Instead, the PIT is used as the trigger for the DMAMUX periodic trigger mode. If you want
to use one of the PIT channels for periodic DMA requests, you would use the periodic trigger
mode in conjunction with one of the "always enabled" DMA requests. However, the DMA
request does not assert correctly in this case.
Instead of sending a single DMA request every time the PIT expires, the first time the PIT
triggers a DMA transfer the "always enabled" source will not negate its request. This results in
the DMA request remaining asserted continuously after the first trigger.
Workaround:
Use of the PIT to trigger DMA channels where the major loop count is greater than one is not
recommended. For periodic triggering of DMA requests with major loop counts greater than
one, we recommended using another timer module instead of the PIT.
If using the PIT to trigger a DMA channel where the major loop count is set to one, then in
order to get the desired periodic triggering, the DMA must do the following in the interrupt
service routine for the DMA_DONE interrupt:
1. Set the DMA_TCDn_CSR[DREQ] bit and configure DMAMUX_CHCFGn[ENBL] = 0
2. Then again DMAMUX_CHCFGn[ENBL] = 1, DMASREQ=channel in your DMA DONE
interrupt service routine so that "always enabled" source could negate its request then DMA
request could be negated.
This will allow the desired periodic triggering to function as expected.
e5751: FTFx: Launching the Read 1's Section command (RD1SEC) on an entire flash
block results in access error (ACCER).
Errata type:
Errata
Description:
FTFx: Launching the Read 1's Section command on an entire flash block (i.e. with flash
address = flash block base address & number of longwords = total number of longwords in the
flash block) results in an incorrectly asserted access error (ACCER).
Workaround:
To verify an entire flash block, use the Read 1's Block command. Use the Read 1's Section
command only to verify sections that are smaller than an entire flash block.
e5706: FTFx: MCU security is inadvertently enabled (secured) if a mass erase is
executed when the flash blocks/halves are swapped. This issue only affects
applications that use the flash swap feature.
Errata type:
Errata
Description:
When the logical addresses of the flash blocks (halves) are swapped via the flash swap control
command sequence and a mass erase is executed (via the MDM-AP or EzPort), the MCU
security can go from un-secure to secure. Thus, when using a debugger to erase the entire
flash memory and re-download a software application, the debugger may report that the device
is secure after the erase completes. This issue only affects applications that use the flash
swap feature.
Workaround:
Issue the mass erase request (via the MDM-AP or EzPort) a second time to un-secure the
device.
Mask Set Errata for Mask 1N89E, Rev 31 JAN 2014
4
Freescale Semiconductor, Inc.