SPRZ491E December   2020  – December 2024 DRA821U , DRA821U-Q1

 

  1.   1
  2. 1Modules Affected
  3. 2Nomenclature, Package Symbolization, and Revision Identification
    1. 2.1 Device and Development-Support Tool Nomenclature
    2. 2.2 Devices Supported
    3. 2.3 Package Symbolization and Revision Identification
  4. 3Silicon Revision 1.0, 2.0 Usage Notes and Advisories
    1. 3.1 Silicon Revision 1.0, 2.0 Usage Notes
    2. 3.2 Silicon Revision 1.0, 2.0 Advisories
    3.     i2049
    4.     i2062
    5.     i2091
    6.     i2103
    7.     i2116
    8.     i2123
    9. 3.3 i2126
    10. 3.4 i2127
    11.     i2134
    12.     i2137
    13.     i2146
    14. 3.5 i2151
    15.     i2157
    16.     i2159
    17.     i2160
    18.     i2161
    19.     i2163
    20.     i2166
    21.     i2177
    22.     i2182
    23.     i2183
    24.     i2184
    25.     i2185
    26.     i2186
    27.     i2187
    28.     i2189
    29.     i2196
    30.     i2197
    31.     i2201
    32.     i2205
    33.     i2207
    34.     i2208
    35.     i2209
    36.     i2216
    37.     i2217
    38.     i2221
    39.     i2222
    40.     i2227
    41.     i2228
    42.     i2232
    43.     i2233
    44.     i2234
    45.     i2235
    46.     i2237
    47.     i2241
    48.     i2242
    49.     i2243
    50.     i2244
    51.     i2245
    52.     i2246
    53.     i2249
    54.     i2253
    55.     i2257
    56.     i2274
    57.     i2275
    58.     i2277
    59.     i2278
    60.     i2279
    61.     i2283
    62.     i2306
    63.     i2307
    64.     i2310
    65.     i2311
    66.     i2312
    67.     i2320
    68.     i2326
    69.     i2329
    70.     i2351
    71.     i2360
    72.     i2361
    73.     i2362
    74.     i2366
    75.     i2371
    76.     i2372
    77.     i2383
    78.     i2401
    79.     i2409
    80.     i2413
    81.     i2414
    82.     i2418
    83.     i2419
    84.     i2422
    85.     i2424
    86.     i2435
    87.     i2459
  5.   Trademarks
  6.   Revision History

i2329

MDIO: MDIO interface corruption (CPSW and PRU-ICSS)

Details:

It is possible that the MDIO interface of all instances of CPSW and PRU-ICSS peripherals (if present) returns corrupt read data on MDIO reads (e.g. returning stale or previous data), or sends incorrect data on MDIO writes. It is also possible that the MDIO interface becomes unavailable until the next peripheral reset (either by LPSC reset or global device reset with reset isolation disabled in case of CPSW).

Possible system level manifestations of this issue could be (1) erroneous ethernet PHY link down status (2) inability to properly configure an ethernet PHY over MDIO (3) incorrect PHY detection (e.g. wrong address) (4) read or write timeouts when attempting to configure PHY over MDIO.

For boot mode (only CPSW if supported), there is no workaround to guarantee the primary ethernet boot is successful. If this exception occurs during primary boot, the boot may possibly initiate retries which may or may not be successful. If the retries are unsuccessful, this would result in an eventual timeout and transition to the backup boot mode (if one is selected). If no backup boot mode is selected, then such failure will result in a timeout and force device reset via chip watchdog after which the complete boot process will restart again.

To select a backup boot option (if supported), populate the appropriate pull resistors on the boot mode pins. See boot documentation for each specific device options, but the typical timeout for primary boot attempts over ethernet is 60 seconds.

Workaround(s):

On affected devices, following workaround should be used:

MDIO manual mode: applicable for PRU-ICSS and for CPSW.

MDIO protocol can be emulated by reading and writing to the appropriate bits within the MDIO_MANUAL_IF_REG register of the MDIO peripheral to directly manipulate the MDIO clock and data pins. Refer to TRM for full details of manual mode register bits and their function.

In this case the device pin multiplexing should be configured to allow the IO to be controlled by the CPSW or PRU-ICSS peripherals (same as in normal intended operation), but the MDIO state machine must be disabled by ensuring MDIO_CONTROL_REG.ENABLE bit is 0 in the MDIO_CONTROL_REG and enable manual mode by setting MDIO_POLL_REG.MANUALMODE bit to 1.

Contact TI regarding implementation of software workaround.

Note: If using Ethernet DLR (Device Level Ring) (on CPSW or PRU-ICSS) or EtherCat protocol (on PRU-ICSS) there may be significant CPU or PRU loading impact to implement the run-time workaround 1 due to required polling interval for link status checks. Resulting system impact should be considered.

In case of PRU-ICSS, the loading of the software workaround may be reduced by using the MLINK feature of MDIO to do automatic polling of link status via the MIIx_RXLINK input pin to PRU-ICSS which must be connected to a status output from the external PHY which does not toggle while the link is active. Depending on the specified behavior of the external PHY device, this PHY status output may be LED_LINK or LED_SPEED or the logic OR of LED_LINK and LED SPEED. Refer to the MDIO section of TRM for details on using the MLINK feature of MDIO. This feature is not available on the CPSW peripheral.

For EtherCAT implementation on PRU-ICSS, the software workaround will be done in RTUx/ TX_PRUx Core. The core will have to be dedicated for workaround, which means this can’t be used for other purpose. The implementation will support two user access channels for MDIO access. This provides option for R5f core and PRU core to have independent access channel. The APIs will be similar to the ones we will have in RTOS Workaround implementation.

EtherCAT will continue to use PHY fast link detection via MDIO MLINK bypassing state m/c for link status (as this path is not affected by errata). This makes sure that cable redundancy related latency requirements are still met.

 MDIO Emulation via Manual Mode using PRU Core Figure 3-2 MDIO Emulation via Manual Mode using PRU Core