NXP Semiconductors Freescale Semiconductor MPC8308 User manual

This document details all known silicon errata for the MPC8308. The following table provides a revision history for
this document.
Table 1. Document Revision History
Revision Date Significant Changes
5 09/2015 Added the following errata:
• eSDHC A-005055 and A-009204
• IEEE1588 A-007734
• PCIe PEX5
• USB A-003845
Added IEEE 1588_19 to Table 3, Summary of Silicon Errata and Applicable Revision.
Modified eTSEC69.
Renamed eTSEC-A002 to A-006502 and modified the write-up.
Renamed "PEX" heading to "PCIe".
Re-ordered the USB errata numerically.
407/2013 Renamed USB38 to USB erratum A-003817
Added the following errata:
• USB errata: A-003837, A-003827, A-003829
• eSDHC erratum: A-004577
Removed erratum DDR20
3 05/2012 • In Table 2, added silicon revision 1.1 SVR and PVR information.
• In Table 3, added silicon revision 1.1 column.
• In Table 3, updated the projected solution for the following errata: IEEE1588-A001,
PCIe- A002, and A-003985.
2 12/2011 • Added eLBC-A002
• Removed eLBC1, eLBC2, eTSEC29, IEEE1588_8, USB21
1 11/2011 • Added USB-A005, USB-A007, CPU-A022, PCIe-A002, A-003985
• Removed SPI6
• Updated USB-A001
0 07/2010 Initial release
Freescale Semiconductor MPC8308CE
Chip Errata Rev. 5, 09/2015
MPC8308 Chip Errata
© 2015 Freescale Semiconductor, Inc.

The following table provides a cross-reference to match the revision code in the processor version register to the
revision level marked on the device.
Table 2. Revision Level to Part Marking Cross-Reference
Part Revision Processor Version Register
Value
System Version Register Value Mask
MPC8308 1.1 8085_0020 8101_0111 M17Y
MPC8308 1.0 8085_0020 8101_0110 M17Y
Table 3 summarizes all known errata.
Table 3. Summary of Silicon Errata and Applicable Revision
Errata Name Projected Solution Silicon Rev.
1.0 1.1
CPU
CPU6 DTLB LRU logic does not function correctly No plans to fix Yes Yes
CPU-A002 CPU may hang after load from cache-inhibited, unguarded
memory
No plans to fix Yes Yes
CPU-A022 The e300 core may hang while using critical interrupt No plans to fix Yes Yes
DDR
DDR21 MCK/MCK AC differential crosspoint voltage outside JEDEC
specifications
No plans to fix Yes Yes
DDR23 DDR read failure due to tDISKEW spec violation No plans to fix Yes Yes
eLBC
eLBC5 LTEATR and LTEAR may show incorrect values under certain
scenarios
No plans to fix Yes Yes
eLBC-A001 Simultaneous FCM and GPCM or UPM operation may
erroneously trigger bus monitor timeout
No plans to fix Yes Yes
eLBC-A002 Core may hang while booting from NAND using FCM No plans to fix Yes Yes
eSDHC
eSDHC16 Manual Asynchronous CMD12 abort operation causes protocol
violations
No plans to fix Yes Yes
eSDHC23 CMD CRC error or CMD index error may be set for CMD
without data while CMD with data is in progress
No plans to fix Yes Yes
eSDHC-A002 BLKATTR[BLKCNT] does not return to 0 after Transfer
Complete for multi-block transfer
No plans to fix Yes Yes
A-004577 PRSSTAT[DLA] bit does not reflect the data line state when any
command with busy (R1b) is issued
No plans to fix Yes Yes
A-005055 A glitch is generated on the card clock with software reset or a
clock divider change
No plans to fix Yes Yes
Table continues on the next page...
MPC8308 Chip Errata, Rev. 5, 09/2015
2 Freescale Semiconductor, Inc.

Table 3. Summary of Silicon Errata and Applicable Revision (continued)
Errata Name Projected Solution Silicon Rev.
1.0 1.1
A-009204 System bus may hang if software register SYSCTL[RSTD] is set
while DMA transactions are active
No plans to fix Yes Yes
eTSEC
eTSEC42 Frame is dropped with collision and HALFDUP[Excess Defer] =
0
No plans to fix Yes Yes
eTSEC58 VLAN Insertion corrupts frame if user-defined Tx preamble
enabled
No plans to fix Yes Yes
eTSEC59 False parity error at Tx startup No plans to fix Yes Yes
eTSEC64 User-defined Tx preamble incompatible with Tx Checksum No plans to fix Yes Yes
eTSEC67 ECNTRL[AUTOZ] not guaranteed if reading MIB counters with
software
No plans to fix Yes Yes
eTSEC68 Half-duplex collision on FCS of Short Frame may cause Tx
lockup
Documentation
update
Yes Yes
eTSEC69 Ethernet controller does not exit from Magic Packet mode when
an oddly formed Magic Packet is received
No plans to fix Yes Yes
eTSEC70 MAC: Malformed Magic Packet Triggers Magic Packet Exit No plans to fix Yes Yes
eTSEC71 The value of TSEC_ID2 is incorrect No plans to fix Yes Yes
eTSEC73 TxBD polling loop latency is 1024 bit-times instead of 512 No plans to fix Yes Yes
eTSEC74 MAC: Rx frames of length MAXFRM or MAXFRM-1 are marked
as truncated
No plans to fix Yes Yes
eTSEC75 Misfiled Packets Due to Incorrect Rx Filer Set Mask Rollback No plans to fix Yes Yes
eTSEC76 Excess delays when transmitting TOE=1 large frames No plans to fix Yes Yes
eTSEC78 Controller may not be able to transmit pause frame during
pause state
No plans to fix Yes Yes
eTSEC-A001 MAC: Pause time may be shorter than specified if transmit in
progress
No plans to fix Yes Yes
A-006502 Incomplete GRS or invalid parser state after receiving a 1- or 2-
byte frame
No plans to fix Yes Yes
IEEE 1588
IEEE 1588_14 TxPAL timestamp uses TxBD snoop enable instead of Tx data No plans to fix Yes Yes
IEEE 1588_16 Odd prescale values not supported No plans to fix Yes Yes
IEEE 1588_17 Cannot use inverted 1588 reference clock when selecting
eTSEC system clock as source
No plans to fix Yes Yes
IEEE 1588_19 Tx FIFO data parity error (DPE) may corrupt Tx timestamps if
TMR_CTRL[TRTPE]=1
No plans to fix Yes Yes
IEEE 1588_20 eTSEC 1588: Write to reserved 1588 register space causes
system hang
No plans to fix Yes Yes
IEEE1588-A001 Incorrect received timestamp or dropped packet when 1588
time-stamping is enabled
Fixed in Rev 1.1 Yes No
A-007734 Stale time stamps and over-flow conditions can occur when
using an external 1588 input clock at certain frequencies
No plans to fix Yes Yes
General
Table continues on the next page...
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 3

Table 3. Summary of Silicon Errata and Applicable Revision (continued)
Errata Name Projected Solution Silicon Rev.
1.0 1.1
General14 Electrostatic Discharge (ESD) may fail to meet the 2KV Human
body body model (HBM)
No plans to fix Yes Yes
General16 Enabling I2C could cause I2C bus freeze when other I2C devices
communicate
No plans to fix Yes Yes
General17 DUART: Break detection triggered multiple times for a single
break assertion
No plans to fix Yes Yes
PCIe
PEX1 No support of PCI Express completions with BCM bit set (PCIX
bridge interface)
No plans to fix Yes Yes
PEX2 DMA Interrupt descriptor race condition (IDRC) No plans to fix Yes Yes
PEX5 PCI Express LTSSM may fail to properly train with a link partner
following HRESET#
No plans to fix Yes Yes
PEX7 Recovery from hot reset or link down No plans to fix Yes Yes
PCIe-A002 PCI Express Packets may be transmitted with excess data on
x1 link
Partially fixed in 1.1 Yes No
RTC
A-003985 Real Time Counter Register (RTCTR) may not work correctly Fixed in Rev 1.1 Yes No
USB
USB15 Read of PERIODICLISTBASE after successive writes may
return a wrong value in host mode
No plans to fix Yes Yes
USB19 USBDR in Host mode does not generate an interrupt upon
detection of a CRC16/PID/Timeout error when a received IN
data packet is corrupted
No plans to fix Yes Yes
USB25 In host mode, when the software forces a port resume by writing
into the FPR bit of the portsc register, the port change detect
interrupt bit is falsely fired
No plans to fix Yes Yes
USB26 NackCnt field is not decremented when received NYET during
FS/LS Bulk/Interrupt mode
No plans to fix Yes Yes
USB27 When an ACK or NAK is sent from the device in response to a
PING, the CERR counter value is not being reset to the initial
value
No plans to fix Yes Yes
USB28 In device mode, when receiving a Token OUT, if a Rx flush
command is issued at the same time, to the same endpoint, the
packet will be lost
No plans to fix Yes Yes
USB29 Priming ISO over SOF will cause transmitting bad packet with
correct CRC
No plans to fix Yes Yes
USB31 Transmit data loss based on bus latency No plans to fix Yes Yes
USB32 Missing SOFs and false babble error due to Rx FIFO overflow No plans to fix Yes Yes
USB33 No error interrupt and no status will be generated due to ISO
mult3 fulfillment error
No plans to fix Yes Yes
USB34 NAK counter decremented after receiving a NYET from device No plans to fix Yes Yes
USB35 Core device fails when it receives two OUT transactions in a
short time
No plans to fix Yes Yes
USB36 CRC not inverted when host under-runs on OUT transactions No plans to fix Yes Yes
Table continues on the next page...
MPC8308 Chip Errata, Rev. 5, 09/2015
4 Freescale Semiconductor, Inc.

Table 3. Summary of Silicon Errata and Applicable Revision (continued)
Errata Name Projected Solution Silicon Rev.
1.0 1.1
USB37 OTG Controller as Host does not support Data-line Pulsing
Session Request Protocol
No plans to fix Yes Yes
USB-A001 Last read of the current dTD done after USB interrupt No plans to fix Yes Yes
USB-A002 Device does not respond to INs after receiving corrupted
handshake from previous IN transaction
No plans to fix Yes Yes
USB-A003 Illegal NOPID TX CMD issued by USB controller with ULPI
interface
No plans to fix Yes Yes
USB-A005 ULPI Viewport not Working for Read or Write Commands With
Extended Address
No plans to fix Yes Yes
USB-A007 Host controller fails to enter the PING state on timeout during
High Speed Bulk OUT/DATA transaction
No plans to fix Yes Yes
A-003817 USB Controller locks after Test mode "Test_K" is completed No plans to fix Yes Yes
A-003827 DATA PID error interrupt issued twice for the same high
bandwidth ISO transfer
No plans to fix Yes Yes
A-003829 Host detects frame babble but does not halt the port or generate
an interrupt
No plans to fix Yes Yes
A-003837 When operating in test mode, the CSC bit does not get set to 1
to indicate a change on CCS
No plans to fix Yes Yes
A-003845 Frame scheduling robustness-Host may issue token too close to
uframe boundary
No plans to fix Yes Yes
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 5

CPU6: DTLB LRU logic does not function correctly
Description: The DTLB is implemented as 2-way set associative with 32 entries per way. EA[15:19] is used
to determine which one of the 32 entries of both ways. When a DTLB miss occurs, normally
the CPU provides information (through SRR1 bit 14, DTLB replacement way) to indicate which
of the two ways the software (DTLB exception handler or the software table walk routine)
should use to bring in the new page. Presumably, the CPU provides the information, through
SRR1 bit 14, based on the LRU (least recently used) algorithm. However, because of this bug,
this is not the case.
In fact, for any given EA[15:19], when a DTLB miss occurs, SRR1 bit 14 always indicates that
way1 should be used or replaced. (Except if it is the very first DTLB miss after hard reset. In
this case, SRR1 bit 14 indicates way0 should be used.)
In other words, if the DTLB exception routine follows the SRR1 bit 14's suggestion to do the
TLB replacement, it always replaces the one in way1. In addition, whatever has been loaded in
way0 is effectively locked and is not replaced.
Impact: Performance degradation due to the reduction of usable DTLB entries.
Workaround: In the software, use one word (32 bits) to keep the record of the DTLB way that is Least
Recently Written (LRW). Use this information to overwrite the SRR1 bit 14 (DTLB replacement
way) when a Data Translation Miss exception occurs. Basically, the LRU (least recently used)
hardware algorithm is changed to an LRW (least recently written) software algorithm.
For the system that has no secondary storage (such as a hard drive), it is highly recommended
to set the C (Change) bit during the DTLB load exception to optimize the performance.
For a system that has a secondary storage and the OS does a page swap, the OS can choose
whether to set the C bit in the DTLB load exception.
If the C bit is set in the DTLB load exception, it can preempt the subsequent DTLB store
exception to the same page. However, since all the pages are marked as changed, during the
page swap all pages must be written back to the secondary storage regardless of whether they
have really been changed or not.
If the C bit is not set in the DTLB load exception with the LRW algorithm, a subsequent store to
the same page as the previous load will use a separate entry. Therefore, one page occupies
both ways. This causes inefficiency for the DTLB allocation but may save time during the page
swap since the page change status is correctly marked.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
6 Freescale Semiconductor, Inc.

CPU-A002: CPU may hang after load from cache-inhibited, unguarded memory
Description: There is a one-core-clock-cycle window of opportunity for a snoop to collide with the data
returned from cache-inhibited memory to a load that has been cancelled. This collision can
hang the data cache in a busy state, prohibiting further data cache accesses. The snoop
address is immaterial.
The load can be cancelled if it meets the following conditions: it was executing speculatively
beyond a conditional branch that resolved unfavorably or was pre-empted by an external
interrupt or decrementer interrupt that took priority. The load must be from a cache-inhibited,
non-guarded memory block. A load from cacheable memory, even if it misses in the cache,
does not hang the data cache in a busy state, and if the memory block is marked guarded, the
load will not be executed out of order.
An external master must put addresses on the bus with the attribute of memory coherency
required (Global) so that the CPU allows snooping of the data cache. External masters have to
be programmed to snoop.
Impact: CPU halts or stops executing on a subsequent load or store that finds the data cache busy.
This load or store does not complete, and the data cache stays busy until a hardware or
software reset (HRESET or SRESET). Debug tools will reveal that the program counter is
stopped and pointing to the load or store that cannot complete.
Workaround: Use one of the following options:
• Set bit 14 in the HID2 register. This bit disables a minor feature that attempted to take
advantage of cache hits under a cancelled cache miss which was still waiting for data.
There should be no performance loss from disabling this feature. HID2[14] is not
implemented on any other e300 devices. Setting it will have no effect on other devices or
any future revisions.
• Mark all data memory blocks from which loads could occur “cacheable” or “guarded.”
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 7

CPU-A022: The e300 core may hang while using critical interrupt
Description: If BOTH critical interrupt AND normal interrupt types are used in a system, the e300 core may
hang.
Impact: The processor may stop dispatching instructions until a hardware reset(HRESET). Debug tools
will not be able to read any register correctly except program counter IAR which points to a
location in the critical interrupt vector.
Workaround: If both critical interrupt and normal interrupt types are used, then instead of using an rfi
instruction at the end of every exception handler, replace the rfi with the following:
1. Disable critical interrupts by setting MSR[CE] to 0 with a mtspr instruction.
2. Copy SRR0 and SRR1 to CSRR0 and CSRR1, respectively.
3. Execute an rfci instruction. This enables MSR[CE] and any other bits that the original rfi
would have set including the MSR[EE].
Sample Code:
// Disable MSR[CE]
mfmsr r2
lis r3, 0xffff
ori r3, r3, 0xff7f
and r2, r2, r3
sync
mtmsr r2
isync
// Copy SRR0, SRR1 to CSRR0 and CSRR1
mfspr r2, srr0
mfspr r3, srr1
mtspr csrr0, r2
mtspr csrr1, r3
...restore GPRs
rfci
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
8 Freescale Semiconductor, Inc.

DDR21: MCK/MCK AC differential crosspoint voltage outside JEDEC specifications
Description: The crossover points of the MCK and MCK signals of the DDR controller are not meeting
JESD79-2C specifications, which indicates that the crossover points should lie within ±125 mV
range of reference voltage.
Impact: Disagreement with the JESD79-2C standard.
Workaround: To meet the JESD79-2C crosspoint voltage specifications, we recommend implementing the
following connections between the DDR controller and DDR2 memory:
Figure 1. Recommended connections for DDR controller and memory
Effect of different circuit components on MCK and MCK signals:
1. Increasing R2 and R3 shifts signal levels up (used as pull up).
2. Increasing C1 increases rise/fall time of mck signal.
3. Increasing C2 increases rise/fall time of mckb signal.
4. Reducing R1 can help in shifting the signals up.
5. R4 and R5 can be used to make termination proper.
Component Placing:
R4, R5, C1, C2 near to SOC, R1, R2, and R3 have been placed at the end of clock
transmission lines.
By considering these suggestions and choosing proper values of components for a particular
board layout, one can keep crossover points within range.
We recommend varying termination resistor R1 first. Lowering R1 can help increase the
voltage levels up. The only disadvantage is that it may add up more reflections. Therefore, the
user must decide accordingly. If it does not give sufficient margin, the user can add the pull-up
resistor (R3 and R4) option to further increase the voltage levels.
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 9

Exact values of components vary from design to design and some of them may not be required
fpr all designs. We recommend that you make provisions for all these options in your design.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
10 Freescale Semiconductor, Inc.

DDR23: DDR read failure due to tDISKEW spec violation
Description: When the minimum voltage swing (500 mV) on inputs specified by JEDEC spec is applied,
there will be violation of tDISKEW parameter.
Impact: DDR read operation is not guaranteed if peak-to-peak input voltage swing is less than 800 mV.
Workaround: Select the parallel termination resistor and configuration such that the peak-to-peak input
voltage swing is more than 800 mV.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 11

eLBC5: LTEATR and LTEAR may show incorrect values under certain scenarios
Description: The eLBC IP acks any transaction request when FCM special operation is in progress. In such
a scenario when any one of the errors/events occur (such as Bus Monitor Timeout, Write
Protect, Parity error, Atomic error, FCM command completion, or UPM command completion
except for the CS error), the registers LTEAR and LTEATR capture the address and attributes
of the most recently req-acked transaction instead of the FCM special operation that caused
error. Hence indeterministic value may show up in those registers.
Impact: LTEAR and LTEATR cannot be used for debugging in this scenario.
Workaround: None
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
12 Freescale Semiconductor, Inc.

eLBC-A001: Simultaneous FCM and GPCM or UPM operation may erroneously trigger
bus monitor timeout
Description: When the FCM is in the middle of a long transaction, such as NAND erase or write, another
transaction on the GPCM or UPM triggers the bus monitor to start immediately for the GPCM
or UPM, even though the GPCM or UPM is still waiting for the FCM to finish and has not yet
started its transaction. If the bus monitor timeout value is not programmed for a sufficiently
large value, the local bus monitor may time out. This timeout corrupts the current NAND Flash
operation and terminate the GPCM or UPM operation.
Impact: Local bus monitor may time out unexpectedly and corrupt the NAND transaction.
Workaround: Set the local bus monitor timeout value to the maximum by setting LBCR[BMT] = 0 and
LBCR[BMTPS] = 0xF.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 13

eLBC-A002: Core may hang while booting from NAND using FCM
Description: When FCM is selected as the boot ROM controller via power-on-reset configuration, eLBC
automatically loads 4K Bytes page of boot code into the FCM buffer RAM. These 4K Bytes
consist of 8 pages (512 bytes each) of small-page NAND flash OR 2 pages (2048 bytes each)
of Large-page NAND flash. The core begins execution as soon as the first page is loaded. If
the core tries to execute an instruction that has not been loaded yet, unpredictable behavior
may result.
Impact: Core might not be able to boot from NAND.
Workaround: Before execution of any instruction located beyond the first page, wait for LTESR[CC] (offset
0xB0) bit to be set. The bit indicates that all the pages have been loaded from NAND to 4K
Bytes FCM buffer RAM.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
14 Freescale Semiconductor, Inc.

eSDHC16: Manual Asynchronous CMD12 abort operation causes protocol violations
Description: There may be protocol violations if a manual (software) asynchronous CMD12 is used to abort
data transfer. Due to this erratum, the eSDHC controller continues driving data after a manual
(software) asynchronous CMD12 is issued. Therefore, it may cause a conflict on the data lines
on the SD bus.
Impact: Manual asynchronous CMD12 to terminate data transfer cannot be used.
Workaround: Do not issue a manual asynchronous CMD12. Instead, use a (software) synchronous CMD12
or AUTOCMD12 to abort data transfer.
Due to erratum A-004577, CMD13 needs to be sent after TC of the data transfer command for
which AutoCMD12 is enabled. See A-004577 for details.
For a manual synchronous CMD12, the following steps are required:
1. Set PROCTL[SABGREQ] = 1
2. Wait for IRQSTAT[TC] bit set, or Transfer Complete Interrupt
3. Set IRQSTAT[TC] = 1
4. Issue CMD12 after checking PRSSTAT[CIHB] = 0
5. Set both SYSCTL[RSTD] and SYSCTL[RSTC]
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 15

eSDHC23: CMD CRC error or CMD index error may be set for CMD without data while
CMD with data is in progress
Description: While a command with data is in progress and a command without data is issued, for example
CMD13, an invalid command CRC error (IRQSTAT[CCE]) and/or command index error
(IRQSTAT[CIE]) might be detected. This can happen when SDHC_CLK shuts off (due to buffer
danger) exactly after START bit of response is detected by the eSDHC. While the clock is
gated, the eSDHC samples an incorrect value from the command line thus sampling an
incorrect command index in the response and eventually generating a command CRC and
index error.
Impact: This issue occurs under a rare condition. The data transfer itself is not impacted.
Workaround: On detecting a command CRC error (IRQSTAT[CCE]) or command index error
(IRQSTAT[CIE]), perform error recovery and re-issue the command without data. If Auto
CMD12 is enabled for data transfer then Auto CMD12 won’t be issued by hardware, so
software needs to issue it after data transfer completion.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
16 Freescale Semiconductor, Inc.

eSDHC-A002: BLKATTR[BLKCNT] does not return to 0 after Transfer Complete for
multi-block transfer
Description: For a multi-block transfer, when the XFERTYP[BCEN](block count enable) is 1,
BLKATTR[BLKCNT] should decrement to 0 after Transfer Complete (TC)((IRQSTAT[TC] = 1).
However, due to this erratum, BLKATTR[BLKCNT] returns to the initial value which was
programmed while issuing the multi-block transfer command.
Impact: The value of BLKATTR[BLKCNT] is unreliable and cannot be read to confirm a Transfer
Complete.
Workaround: For a multi-block transfer, after IRQSTAT[TC] = 1, software should not rely on the value of
BLKATTR[BLKCNT].
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 17

A-004577: PRSSTAT[DLA] bit does not reflect the data line state when any command
with busy (R1b) is issued
Affects: eSDHC
Description: When an AutoCMD12 or any command with busy (R1b) is issued, PRSSTAT[DLA] bit should
reflect the data line state. However, due to this erratum, PRSSTAT[DLA] is not applicable to
detect data busy state. Furthermore, the corresponding transfer complete interrupt is not
generated. However, the AutoCMD12 or any command with busy (R1b) can still be used with
the restriction that busy needs to be de-asserted before sending new data command.
Impact: When an AutoCMD12 or any command with busy (R1b) is issued, PRSSTAT[DLA] bit does not
reliably reflect the data line state.
Workaround: Software needs to wait for busy de-assertion before issuing any new data command. DAT0
line could be polled, but robust solution would be to keep sending CMD13(SEND_STATUS)
until card reaches “trans" state.
• For AutoCMD12, CMD13 needs to be sent after TC of the data transfer command for
which AutoCMD12 is enabled.
• For other command with busy, CMD13 needs to be sent after the command with busy
completion(IRQSTAT[CC] = 1).
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
18 Freescale Semiconductor, Inc.

A-005055: A glitch is generated on the card clock with software reset or a clock
divider change
Affects: eSDHC
Description: A glitch may occur on the SDHC card clock when the software sets the SYSCTL[RSTA] bit
(that is, performs a software reset). It can also be generated by setting the clock divider value.
The glitch produced can cause the external card to switch to an unknown state. The
occurrence is not deterministic and it happens rarely. The next command causes a timeout
error(IRQSTAT[CTOE]) after this issue occurs.
Impact: Changing the frequency or performing a software reset for all may not work reliably.
Workaround: When the timeout error occurs for the command right after the SYSCTL[RSTA] is set or the
clock divider value is changed, send CMD0 to bring the card to idle state, and perform re-
initialization again. If the error occurs again, repeat this step until the initialization process
completes.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
Freescale Semiconductor, Inc. 19

A-009204: System bus may hang if software register SYSCTL[RSTD] is set while DMA
transactions are active
Affects: eSDHC
Description: In the event of that any data error (like, IRQSTAT[DCE]) occurs during an eSDHC data
transaction where DMA is used for data transfer to/from the system memory, setting the
SYSCTL[RSTD] register may cause a system hang. If software sets the register
SYSCTL[RSTD] to 1 for error recovery while DMA transferring is not complete, eSDHC may
hang the system bus. This happens because the software register SYSCTL[RSTD] resets the
DMA engine without waiting for the completion of pending system transactions.
Impact: Causes system bus to hang.
Workaround: Add a 5 ms delay before setting SYSCTL[RSTD] to make sure all the DMA transfers are
finished.
Fix plan: No plans to fix
MPC8308 Chip Errata, Rev. 5, 09/2015
20 Freescale Semiconductor, Inc.