Chip Errata for the i.MX28

Freescale Semiconductor
Errata
Document Number: IMX28CE
Rev. 2, 09/2012
Chip Errata for the
i.MX28
This document details all known silicon errata for the i.MX28. Table 1 provides a revision history for this
document.
Table 1. Document Revision History
Rev.
Number
Date
2
09/2012
• Added errata ERR002656, ERR002360, 2765, 2858, 2814, 2811, TKT131240, 5837 and
TKT140334.
1
09/2010
• Updated Table 2
• Deleted ENGR119940
0
03/2010
Initial release.
Substantive Change(s)
Table 2 provides a cross-reference to match the revision code to the revision level marked on the device.
Table 2. Revision Level to Part Marking Cross-Reference
MCIMX28 Revision
Package
Device Marking
Mask Revision
1.2
14 x 14
MCIMX283DVM4B
M06Z
1.2
14 x 14
MCIMX283CVM4B
M06Z
1.2
14 x 14
MCIMX286DVM4B
M06Z
1.2
14 x 14
MCIMX286CVM4B
M06Z
1.2
14 x 14
MCIMX287CVM4B
M06Z
1.2
14 x 14
MCIMX281AVM4B
M06Z
1.2
14 x 14
MCIMX285AVM4B
M06Z
© 2012 Freescale Semiconductor, Inc. All rights reserved.
Table 2. Revision Level to Part Marking Cross-Reference
MCIMX28 Revision
Package
Device Marking
Mask Revision
1.2
14 x 14
MCIMX280DVM4B
M06Z
1.2
14 x 14
MCIMX280CVM4B
M06Z
Table 3 summarizes all known errata.
Table 3. Summary of Silicon Errata and Applicable Revision
Errata
Name
Projected Solution
ENGR116296
HSADC: Soft reset causes unexpected request to DMA
No fix scheduled
ENGR116904
PXP: The HW_PXP_CSCCOEFF2_C3 register can not be reset correctly under
some PVT corner
No fix scheduled
ENGR119650
USB: USB core INCR8 and INCR16 modes are inoperable
No fix scheduled
ENGR119653
USB: ARM to USB register error issue
No fix scheduled
ENGR119657
PWM: Register write sync issue when HSADC clock frequency is lower than
APBX clock frequency
No fix scheduled
ENGR119956
CLKCTRL: ENET 1588 clock (CLK_ENET_TIME) is not under control of ENET
disable control bit
No fix scheduled
ENGR121613
ENET: ENET big endian mode not compatible with ARM little endian
No fix scheduled
ENGR121616
DMA: APBH/APBX DMA channel can stall while waiting to access a APBH/APBX
bus peripheral when the channel freeze bit is set
No fix scheduled
ERR002656
FlexCAN: Abort request blocks the CODE field
No fix scheduled
ERR002360
FlexCAN: Global Masks misalignment
No fix scheduled
2765
EMI Clock: Switching to synchronous mode error
No fix scheduled
2858
USB controller may access a wrong address for the dTD (endpoint transfer
descriptor) and then hangs
No fix scheduled
2814
The DCDC converters unexpectedly turn on when 5 V is removed while the
DCDC_XFER bit is clear
No fix scheduled
2811
Unreliability of VDD5V_GT_VDDIO functionality
No fix scheduled
TKT131240
SSP0/1-SD/MMC/eMMC Boot: SSP_SCK polarity setup issue in ROM
No fix scheduled
5837
Setting the ENABLE_DCDC bit in the HW_POWER_DCDC4P2 or
HW_POWER_5VCTRL registers can result in false brownout Detection
No fix scheduled
ONFI 3.0 NAND boot-up issue
No fix scheduled
TKT140334
Chip Errata for the i.MX28, Rev. 2
2
Freescale Semiconductor
ENGR116296
ENGR116296
HSADC: Soft reset causes unexpected request to DMA
Description:
When HSADC is initially powered on and performs a soft reset, the APBH-DMA may receive an
unexpected request from the HSADC and enter into an unknown state.
Projected Impact:
HSADC operates incorrectly.
Workaround:
Software workaround 1:
Before completing a normal soft reset, make a timing sequence of CLKGATE and SFTRST by
register programming to reset FIFO read and write pointer, and make RD_EMPTY to the
known state of 1 before normal operation.
The register programming below can be used to generate the timing sequence of CLKGATE
and SFTRST before a normal soft reset.
— HW_HSADC_CTRL0_CLR(BM_HSADC_CTRL0_SFTRST);
— HW_HSADC_CTRL0_WR((HW_HSADC_CTRL0_RD() |
BM_HSADC_CTRL0_SFTRST) & (~BM_HSADC_CTRL0_CLKGATE));
— HW_HSADC_CTRL0_SET(BM_HSADC_CTRL0_CLKGATE);
— HW_HSADC_CTRL0_CLR(BM_HSADC_CTRL0_CLKGATE);
— HW_HSADC_CTRL0_SET(BM_HSADC_CTRL0_CLKGATE);
NOTE
This sequence is only required for the first reset after power up.
Software workaround 2:
Complete a HSADC DMA channel reset after the HSADC module soft reset and before
configuring/enabling the HSADC DMA channel as shown below:
— HW_APBH_CHANNEL_CTRL.B.RESET_CHANNEL = 0x1000;
— HSADC_CTRL0_CLKGATE and HSADC_CTRL0_SFTRST address is 0x80002000.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
3
ENGR116904
ENGR116904
PXP: The HW_PXP_CSCCOEFF2_C3 register can not be reset
correctly under some PVT corner
Description:
The HW_PXP_CSCCOEFF2_C3 register does not receive the correct reset value after using the
PXP software reset function or after power up.
Projected Impact:
The PXP operates incorrectly with wrong coefficient setting.
Workaround:
Always write the HW_PXP_CSCCOEFF2_C3 register with the expected value before using it. The
PXP_CSCCOEFF2 register address is 0x8002A0F0.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
4
Freescale Semiconductor
ENGR119650
ENGR119650
USB: USB core INCR8 and INCR16 modes are inoperable
Description:
The USB controller may not operate properly when receiving a packet in INCR8 and INCR16
modes. The packet is completed correctly (ACK is sent) on the USB bus, but cannot be seen by
software.
This issue exists when all of following conditions are met:
1. Controller is receiving data (Host Bulk IN or Device Bulk OUT)
2. Primary INCR8/INCR16 mode is selected (SBUSCFG. AHBBRST of the USB register is set
to 0b010 or 0b011)
3. Length of data received is less than the total_byte field in TD
4. Data length is not a multiple of the burst size and the remainder is a sub-burst. For example, if
the data length is 32n + 16 bytes in INCR8 mode, or 64n + 16/32/48 in INCR16 mode, this
errata is triggered.
Projected Impact:
This is a low severity bug because INCR8 and INCR16 are not mandatory modes. Other modes
should be used.
Workaround:
Set SBUSCFG.AHBBRST of the USB register to a modes other than 0b010 or 0b011.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
5
ENGR119653
ENGR119653
USB: ARM to USB register error issue
Description:
The ARM writes a data error to the USB core register unless SRM SWP instruction is used.
The issue occurs when all of the following conditions are met:
1. Last AHB access is to the non-USB AHB slave
2. Current AHB access is to the USB
3. These two accesses are back-to-back
4. The last data phase of the last AHB access has a wait state
5. Only happens when D-cache is enabled
Projected Impact:
The USB register does not get correct data when writing to the USB slave through the AHB bus
when D-cache is enabled.
Workaround:
All USB register write operations must use the ARM SWP instruction.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
6
Freescale Semiconductor
ENGR119657
ENGR119657
PWM: Register write sync issue when HSADC clock frequency is
lower than APBX clock frequency
Description:
The PWM channel might not generate the required output signal when in HSADC driving mode.
When in HSADC mode, if the HSADC input clock is much lower than the APBX bus clock (for
example APBX Bus clock is 24 MHz and HSADC input clock is 4 MHz) the write signal to the
PWM registers is missed. Write access to the following registers has no effect after HSADC mode
is enabled:
• PWM Control and Status Register
• PWM Channel Active Register
• PWM Channel Period Register
As a result, dedicated PWM channel is not triggered.
Projected Impact:
HSADC or off chip linear sensor does not receive the required control signals.
Workaround:
If the HSADC input clock is lower than the 24 MHz APBX bus clock the APBX bus clock should
be set to a lower frequency before every write to the PWM register. When the write access finishes,
the APBX clock can be set back to normal.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
7
ENGR119956
ENGR119956
CLKCTRL: ENET 1588 clock (CLK_ENET_TIME) is not under control
of ENET disable control bit
Description:
The Ethernet 1588 clock (CLK_ENET_TIME) continues to toggle when the Ethernet module is
disabled by setting ENET disable control bit in the HW_CLKCTRL_ENET register. The ethernet
controller consumes 30 μA on the 4.2 V power supply.
Projected Impact:
The Ethernet 1588 clock consumes 30 μA on the 4.2 V power supply when the Ethernet module is
disabled.
Workaround:
The Ethernet 1588 clock can be gated off by clearing the HW_CLKCTRL_ENET_DIV_TIME
register. The HW_CLKCTRL_ENET_DIV_TIME register address is 0x80040140.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
8
Freescale Semiconductor
ENGR121613
ENGR121613
ENET: ENET big endian mode not compatible with ARM little endian
Description:
The endian mode of the Ethernet controller is designed to be big-endian mode which is not
compatible with the ARM core and reset sections of the device.
Projected Impact:
The ARM core cannot establish data communication correctly to/from the Ethernet controller
without software endian conversion.
Workaround:
When communicating with the Ethernet controller, an additional byte-swap routine has to be called
by the ARM core.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
9
ENGR121616
ENGR121616
DMA: APBH/APBX DMA channel can stall while waiting to access a
APBH/APBX bus peripheral when the channel freeze bit is set
Description:
When the channel freeze bit is set, the APBH/APBX DMA channel can stall while waiting to
access a peripheral on the APBH/APBX bus. This occurs if the channel freeze bit is set exactly at
the same time as when the channel internal state machine changes from the PIO_REQ state to the
REQ_WAIT state.
Projected Impact:
The data communication with the APBH/APBX DMA channel associated peripheral is stalled.
Workaround:
Do not use DMA PIO operation to configure the associated peripheral when using channel freeze
function. Use ARM PIO operation instead.
Projected Solution:
No fix scheduled
Chip Errata for the i.MX28, Rev. 2
10
Freescale Semiconductor
ERR002656
No fix scheduled.
ERR002656
FlexCAN: Abort request blocks the CODE field
Description:
An Abort request to a transmit message buffer (TxMB) can block any write operation into its
CODE field. Therefore, the TxMB cannot be aborted or deactivated until it completes a valid
transmission (by winning the CAN bus arbitration and transmitting the contents of the TxMB).
Projected Impact:
The TxMB cannot be aborted or deactivated until it completes a valid transmission.
Workaround:
Instead of aborting the transmission, use deactivation instead.
Note that there is a chance the deactivated TxMB can be transmitted without setting IFLAG
and updating the CODE field if it is deactivated.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
11
ERR002360
ERR002360
FlexCAN: Global Masks misalignment
Description:
During CAN message reception by FlexCAN, the RXGMASK (Rx Global Mask) is used as an
acceptance mask for most of the Rx message buffers (MB). When the FIFO Enable bit in the
FlexCAN Module Configuration Register (CANx_MCR[FEN], bit 29) is set, the RXGMASK also
applies to most of the elements of the ID filter table. However, there is a misalignment between the
position of the ID field in the RxMB and that in the RXIDA, RXIDB and RXIDC fields of the ID
tables. In fact, the RXIDA filter in the ID tables is shifted one bit to the left from the RxMBs ID
position, as shown below:
RxMB ID = bits 28-0 of ID word corresponding to message ID bits 28-0
RXIDA = bits 29-1 of ID Table corresponding to message ID bits 28-0
Note that the mask bits align to the ID filter bits, not to the incoming ID bits. For example, the bit
4 in RXGMASK masks bit 4 in RxMB ID, but it does not mask bit 4 in incoming message ID. This
misalignment leads the RXGMASK to affect RxMB and Rx FIFO filtering in different ways.
For example, if the user intends to mask out bit 4 of the ID filter of message buffer then the
RXGMASK will be configured as 0xffff_ffef. As a result, bit 4 of the ID field of the incoming
message is ignored during the filtering process for message buffers. This very same configuration
of RXGMASK, which would lead bit 4 of RXIDA to be “do not care” and thus bit 3 of the ID field
of the incoming message would be ignored during the filtering process for the Rx FIFO.
Similarly, both RXIDB and RXIDC filters have multiple misalignments with regards to position of
the ID field in the RxMBs, which can lead to erroneous masking during the filtering process for
either Rx FIFO or MBs.
RX14MASK (Rx 14 Mask) and RX15MASK (Rx 15 Mask) have the same structure as the
RXGMASK. This includes the misalignment problem between the position of the ID field in the
RxMBs and in the RXIDA, RXIDB and RXIDC fields of the ID Tables.
Projected Impact:
Leading to mask misalignment between RxMB and Rx FIFO filtering.
Workaround:
It is recommended that one of the following actions be taken to avoid problems:
• Do not enable the RxFIFO. If CANx_MCR[FEN]=0 then the Rx FIFO is disabled and thus the
masks RXGMASK, RX14MASK and RX15MASK do not affect it.
Chip Errata for the i.MX28, Rev. 2
12
Freescale Semiconductor
ERR002360
• Enable Rx Individual Mask Registers. If the Backwards Compatibility Configuration bit in the
FlexCAN Module Configuration Register (CANx_MCR[BCC], bit 16) is set then the Rx
Individual Mask Registers (RXIMR0-63) are enabled and thus the masks RXGMASK,
RX14MASK and RX15MASK are not used.
• Do not use the masks RXGMASK, RX14MASK and RX15MASK (leave them in reset value
which is 0xffff_ffff) when CANx_MCR[FEN]=1 and CANx_MCR[BCC]=0. In this case,
filtering processes for both RxMBs and Rx FIFO are not affected by those masks.
• Do not configure any MB as Rx (leave all MBs as either Tx or inactive) when
CANx_MCR[FEN]=1 and CANx_MCR[BCC]=0. In this case, the masks RXGMASK,
RX14MASK and RX15MASK can be used to affect ID tables without affecting filtering process
for RxMBs.
Projected Solution:
No fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
13
2765
2765
EMI Clock: Switching to synchronous mode error
Description:
In order to switch the EMI clock from asynchronous to synchronous mode, both the xtal_ref and
the cpu_ref must be active, even if both BYPASS_CPU and BYPASS_EMI are set in the
HW_CLKCTRL_CLKSEQ register.
Projected Impact:
The i.MX28 locks up.
Workaround:
If cpu_ref is inactive, then activate the cpu_ref before attempting to switch to synchronous mode.
Projected Solution:
No fix scheduled
Chip Errata for the i.MX28, Rev. 2
14
Freescale Semiconductor
2858
2858
USB controller may access a wrong address for the dTD (endpoint
transfer descriptor) and then hangs
Description:
Currently, software checks the active bit in dTD to see whether it is finished. If the Active bit is 0,
then software frees the allocated memory for the dTD.
The hardware sequence after all data of a dTD is transferred is as follows:
1. Update the dTD. This includes an AHB write access of three DWords. The active bit is cleared
in the first DW write.
2. Update the qHead (this includes an AHB write access of three DWords).
3. Read the dTD again to check if software added a new dTD (this is a SINGLE AHB read). At
the same time, send out an interrupt if needed.
After step 1, if software finds the Active bit is cleared, then the dTD memory space is freed and
may be allocated for another thread’s use. In step 3, hardware may get a wrong dTD.
This issue does not occur if some delay is added before freeing the dTD memory space.
This issue only occurs in USB INCR8 mode, because steps 1 and 2 have 6 SINGLE AHB transfers
in INC8 mode, but only two burst AHB transfers in INCR mode.
This issue only occurs when the dTD list is used; because if only one dTD is used, the software
only checks the Active bit after an interrupt is received (step 3). However, when the dTD list is
used, the software may check the entire list after the interrupt for the first dTD is received, when
the hardware has just finished the transfer of the second dTD.
Figure 1 illustrates this issue.
Figure 1. dTD Issue Sequence of Events
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
15
2858
Projected Impact:
USB Controller may hang if dTD is freed too quickly.
Workaround:
Postpone freeing the current dTD; free it when its next dTD can be freed, so the last completed dTD
(followed by an ACTIVE dTD) is always freed when the next IOC irq comes.
Projected Solution:
No fix scheduled
Chip Errata for the i.MX28, Rev. 2
16
Freescale Semiconductor
2814
2814
The DCDC converters unexpectedly turn on when 5 V is removed
while the DCDC_XFER bit is clear
Description:
If the DCDC_XFER bit is clear, the DCDC converter should not automatically turn on when 5 V
is removed. Instead, a power-down should occur if 5 V is removed, when DCDC_XFER and
ENABLE_DCDC are zero.
Projected Impact:
DCDC converter input source may switch to DCDC_BATT pin but no power source is present
there. This may latch-up the DCDC converter circuit.
Workaround:
In order to power down the system properly when 5 V is removed, set PWDN_5VBRNOUT bit in
Register HW_POWER_5VCTRL.
Projected Solution:
No fix scheduled
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
17
2811
2811
Unreliability of VDD5V_GT_VDDIO functionality
Description:
Due to unreliability of the VDD5V_GT_VDDIO functionality, the power supply should never be
configured to be used as the 5-V plug/unplug detection method.
Projected Impact:
VDD5V_GT_VDDIO output may not change to “0” (and VDD5V_GT_VDDIO_IRQ may not be
triggered) when 5 V is unplugged.
Workaround:
Use the VBUSVALID comparator for 5V plug/unplug detection. Actually, the VBUSVALID
comparator is recommended in the reference manual, not VDD5V_GT_VDDIO.
The VBUSVALID_5VDETECT bit in HW_POWER_5VCTRL should be set to “1” (it’s default
value) and never cleared. The detection threshold can be changed in the VBUSVALID_TRSH bit
field in HW_POWER_5VCTRL.
Projected Solution:
No silicon fix scheduled.
Chip Errata for the i.MX28, Rev. 2
18
Freescale Semiconductor
TKT131240
TKT131240
SSP0/1-SD/MMC/eMMC Boot: SSP_SCK polarity setup issue in ROM
Description:
When boot mode is set as boot from SD/MMC/eMMC on SSP0/1, the SSP_SCK polarity is not
correctly set up in ROM. The POLARITY bit in HW_SSP_CTRL1 register should be set to “1”
(command and data output on falling edge of clock) according to SD/MMC/eMMC specification.
However, the POLARITY bit is set to “0” in ROM in the existing silicon (TO1.2). As a result, input
setup time (tISU) at SD/MMC/eMMC input may not be met.
Projected Impact:
Write command error may occur when booting from the SD/MMC/eMMC on SSP0/1 and result
in boot failure.
Workaround:
If tISU at SD/MMC/eMMC input is violated and write command error occurs during boot from
SD/MMC/eMMC, a ROM patch of 1kByte size loaded from the EEPROM is required to fix this
issue. Boot mode should be set to [0001] for the EEPROM on I2C0 or [1000] for the EEPROM on
SPI3. The patch executes from the EEPROM, patches the ROM SSP driver code, and switches boot
to either SSP0 or SSP1. There are separate patch binaries to boot from SSP0 and SSP1.
Projected Solution:
No silicon fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
19
5837
5837
Setting the ENABLE_DCDC bit in the HW_POWER_DCDC4P2 or
HW_POWER_5VCTRL registers can result in false brownout
Detection
Description:
When the ENABLE_DCDC bit in HW_POWER_DCDC4P2 or HW_POWER_5V_CTRL is set, a
glitch is propagated through the brownout comparators. If the glitch is sufficiently large, it can
cause a false brownout detection. The VDDD, VDDA, VDDIO, and VBUSVALID comparators are
all susceptible to the glitch.
Projected Impact:
Can result in a false brownout detection.
Workaround:
The sequence below is needed to work around this issue prior to setting the ENABLE_DCDC bit
in HW_POWER_DCDC4P2:
1. Disable the power rail brownout interrupts (clear HW_POWER_CTRL VDDA, VDDD,
VDDIO ENIRQ bits).
2. Set the HW_POWER_5VCTRL PWRUP_VBUS_CMPS bit.
3. Set the HW_POWER_5VCTRL VBUSVALID_TRSH to 0x0 (2.9 V).
4. Set the HW_POWER_5VCTRL VBUSVALID_5VDETECT bit to 1.
5. Disable VBUSDROOP status and interrupts (clear VDD5V_DROOP_IRQ).
6. Set the ENABLE_DCDC bit in HW_POWER_DCDC4P2.
7. Wait 100 µs
8. Check VBUSVALID_IRQ bit. If it is set, then set and clear the PWD_CHARGE_4P2 bit to
repower on the 4P2 regulator because it is automatically shut off on a VBUSVALID false
condition. It may be helpful to ramp up the CHARGE_4P2_ILIMIT value at this point to
gradually draw power from 5 V rail. If HW_POWER_5VCTRL ENABLE_DCDC is already
set, the DCDC will draw current from VDD4P2 as soon as PWD_CHARGE_4P2 is cleared.
9. Clear VBUSDROOP, VBUSVALID, and the output rails IRQ bits as needed.
10. Restore the output rail ENIRQ bits, the VBUSVALID_TRSH level,
VBUSVALID_5VDETECT value, ENIRQ_VBUS_VALID, and ENIRQ_VDD5V_DROOP to
their original values.
The sequence below is needed to work-around this issue prior to setting the ENABLE_DCDC bit in
HW_POWER_5VCTRL and HW_POWER_DCDC4P2. Note that the below workaround assumes the
usual requirements for setting the HW_POWER_5VCTRL ENABLE_DCDC bit are met (that is, the
hardware and/or software battery brownout protection mechanism is enabled to properly protect the
system against the DCDC sourcing from the battery if the battery voltage is too low).
1. Disable the power rail brownout interrupts (clear HW_POWER_CTRL VDDA, VDDD,
VDDIO ENIRQ bits).
Chip Errata for the i.MX28, Rev. 2
20
Freescale Semiconductor
5837
2.
3.
4.
5.
6.
7.
8.
Set the HW_POWER_5VCTRL PWRUP_VBUS_CMPS bit.
Set the HW_POWER_5VCTRL VBUSVALID_TRSH to 0x0 (2.9 V).
Set the HW_POWER_5VCTRL VBUSVALID_5VDETECT bit to 1.
Disable VBUSDROOP status and interrupts (clear VDD5V_DROOP_IRQ).
Set the ENABLE_DCDC bit in HW_POWER_5VCTRL.
Wait 100 µs.
Check VBUSVALID_IRQ bit. If it is set, and 5 V is present and the VDD4P2 rail was enabled,
then repeat the sequence for enabling the 4P2 regulator and DCDC from VDD4P2. This bit
indicates that the DCDC has tried to source from the battery, even if 4P2 sourcing is enabled.
This is because a VBUSVALID false condition automatically disables the 4P2 regulator, so the
DCDC then falls back to battery sourcing.
9. Clear VBUSDROOP, VBUSVALID, and the output rails IRQ bits as needed.
10. Restore the output rail ENIRQ bits, the VBUSVALID_TRSH level,
VBUSVALID_5VDETECT value, ENIRQ_VBUS_VALID, and ENIRQ_VDD5V_DROOP to
their original values.
Projected Solution:
No silicon fix scheduled.
Chip Errata for the i.MX28, Rev. 2
Freescale Semiconductor
21
TKT140334
TKT140334
ONFI 3.0 NAND boot-up issue
Description:
ROM in existing silicon (TO1.2) supports ONFI BA-NAND boot-up. During boot-up it reads Bit
7 of Byte 6-7 (1=supports Block Abstracted access mode) in ONFI NAND device’s parameter page
to determine if the NAND device is ONFI BA-NAND. BA-NAND memory devices are no longer
part of the ONFI spec and memory vendors do not support these devices anymore. However in
ONFI 3.0 Spec, that bit has been re-used to specify whether the NAND device supports extended
parameter page.
When a system is mounted with ONFI 3.0 NAND device with “supports extended parameter page”
bit set to “1”, the i.MX28 boot ROM will see it as BA-NAND and will use BA-NAND commands
to access the NAND device. As a result, the system will fail to boot-up.
Projected Impact:
System mounted with ONFI 3.0 NAND device will fail to boot-up.
Workaround:
Contact ONFI NAND vendor to supply NAND device with the “supports extended parameter
page” bit set to “0”, so that the i.MX28 boot ROM will not treat it as BA-NAND.
Projected Solution:
No silicon fix scheduled.
Chip Errata for the i.MX28, Rev. 2
22
Freescale Semiconductor
How to Reach Us:
Information in this document is provided solely to enable system and software
Home Page:
freescale.com
implementers to use Freescale products. There are no express or implied copyright
Web Support:
freescale.com/support
information in this document.
licenses granted hereunder to design or fabricate any integrated circuits based on the
Freescale reserves the right to make changes without further notice to any products
herein. Freescale makes no warranty, representation, or guarantee regarding the
suitability of its products for any particular purpose, nor does Freescale assume any
liability arising out of the application or use of any product or circuit, and specifically
disclaims any and all liability, including without limitation consequential or incidental
damages. “Typical” parameters that may be provided in Freescale data sheets and/or
specifications can and do vary in different applications, and actual performance may
vary over time. All operating parameters, including “typicals,” must be validated for each
customer application by customer’s technical experts. Freescale does not convey any
license under its patent rights nor the rights of others. Freescale sells products
pursuant to standard terms and conditions of sale, which can be found at the following
address: freescale.com/SalesTermsandConditions.
Freescale and the Freescale logo are trademarks of Freescale
Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. All other product or service
names are the property of their respective owners. ARM is the registered
trademark of ARM Limited. ARM9 is a trademark of ARM Limited.
© 2012 Freescale Semiconductor, Inc.
Document Number: IMX28CE
Rev. 2
09/2012