03.08.2013 Views

MPC8548 PowerQUICC III Silicon Changes from Version 2.1.x to ...

MPC8548 PowerQUICC III Silicon Changes from Version 2.1.x to ...

MPC8548 PowerQUICC III Silicon Changes from Version 2.1.x to ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Software Impact of Errata Differences<br />

The workaround stated above will have the same behavior on silicon versions <strong>2.1.x</strong> and 3.1.x. As a result<br />

of this erratum fix in silicon version 3.1.x, an invalid CRC is always appended when an error is detected<br />

for a transmit frame, regardless of the FIFOCFG[CRCAPP] value. Software-implemented CRCs are now<br />

supported with silicon version 3.1.x, since an invalid CRC will be appended if the frame has any error.<br />

3.1.19 eTSEC 79: Generation of Ethernet Pause Frames May Cause Tx<br />

Lockup and False BD Close<br />

Software workaround:<br />

• Option 1: Disable transmit flow control by setting MACCFG1[Tx_flow] = 0.<br />

• Option 2: Run with a minimum platform (CCB) frequency of 500 MHz <strong>to</strong> insure correct Ethernet<br />

operation at gigabit data rates. This workaround only applies <strong>to</strong> Ver <strong>2.1.x</strong>.<br />

• Option 3: Use the following method <strong>to</strong> detect TX lock up and recover <strong>from</strong> it.<br />

Moni<strong>to</strong>r Transmit Packet Counter TPKT and or Transmit Buffer Descrip<strong>to</strong>r Pointers TBPTRn by<br />

software and if no change is detected in the expected time (several multiple of maximum transition<br />

time), and the Transmit halt of ring n bits in the transmit status register TSTAT[THLTn] is not set,<br />

assume the transmitter is stuck by the above condition and proceed with the following recovery<br />

mechanism:<br />

a) Set DMACTRL[GRS] = 1 <strong>to</strong> perform a graceful receive s<strong>to</strong>p.<br />

b) Wait for IEVENT[GRSC] <strong>to</strong> be set, indicating s<strong>to</strong>p complete.<br />

c) Set DMACTRL[GTS] = 1 <strong>to</strong> perform a graceful transmit s<strong>to</strong>p.<br />

d) Wait for IEVENT[GTSC] <strong>to</strong> be set, indicating s<strong>to</strong>p complete.<br />

e) Write a 1 <strong>to</strong> IEVENT[GTSC] <strong>to</strong> acknowledge the event.<br />

f) Clear MACCFG1[Tx_Flow].<br />

g) Wait 256 TX_CLK cycles.<br />

h) Clear MACCFG1[Tx_EN].<br />

i) Wait 3 TX_CLK cycles.<br />

j) Set MACCFG1[TX_EN] and MACCFG1[Tx_Flow].<br />

k) Set DMACTRL[GTS] = 0 <strong>to</strong> clear the graceful transmit s<strong>to</strong>p.<br />

l) Set DMACTRL[GRS] = 0 <strong>to</strong> clear the graceful receive s<strong>to</strong>p.<br />

The workaround stated above has the same behavior on silicon versions <strong>2.1.x</strong> and 3.1.x. As a result of this<br />

erratum being fixed in silicon version 3.1.x, the workarounds are no longer necessary, but will not<br />

adversely impact device functionality.<br />

3.1.20 eTSEC 81: eTSEC Does Not Verify IPv6 Routing Header Type Field<br />

Software workaround:<br />

If this device is operating in a network that is using non-type0 IPv6 routing headers, then the upper<br />

layer processing (IPv6 extension headers and payload checksumming operations) must be<br />

performed in software.<br />

<strong>MPC8548</strong> <strong>PowerQUICC</strong> <strong>III</strong> <strong>Silicon</strong> <strong>Changes</strong> <strong>from</strong> <strong>Version</strong> <strong>2.1.x</strong> <strong>to</strong> <strong>Version</strong> 3.1.x, Rev. 0<br />

10 Freescale Semiconduc<strong>to</strong>r

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!