CRITICALITY

Medium

DESCRIPTION

If read/write accesses are performed concurrently from one initiator to the IODELAY module address space and one initiator to another peripheral address space in the L4_PER2 segment of the L4 interconnect then the access to the IODELAY module can hang, leading to an overall system hang. The concurrent accesses may be from two different initiators, or could be from one initiator capable of issuing multiple transactions through the interconnect. In this context, initiator can be a compute core (MPU, DSP, IPU, etc) or a DMA/Master peripheral (EDMA, SDMA, etc.)

The hang occurs due to a protocol violation on the interconnect OCP bus when responses from the IODELAY module and other module on the L4_PER2 segment occur on the same cycle.

The condition which hangs the system can be avoided by performing all IODELAY configurations during initial MPU boot, before other initiators are enabled. This approach may be acceptable for many peripherals, but may pose limitations for a few peripherals. For example, this approach may limit data transfer speeds of an SD Card or other device attached to the MMCn interface since IODELAY normally changes when the transfer mode is changed during run-time. In this example, the hang may occur if other initiators are accessing peripherals on L4_PER2 while IODELAY is changed to support a new SD Card or MMC transfer mode.

The following peripherals are connected to L4_PER2 and should not be accessed while IODELAY configuration is modified: UART7, UART8, UART9, MCASP4_DAT, MCASP5_DAT, MCASP6_DAT, MCASP7_DAT, MCASP8_DAT, MCASP1_CFG, MCASP2_CFG, MCASP3_CFG, MCASP4_CFG, MCASP5_CFG, MCASP6_CFG, MCASP7_CFG, MCASP8_CFG, GMAC_SW, PWMSS1, PWMSS2, PWMSS3, ATL, MLB, VCP1, VCP2, DCAN2.

WORKAROUND

Avoid accessing other peripherals that are on the L4_PER2 segment of the interconnect while IODELAY configuration is occurring. This can be accomplished by performing all IODELAY configurations during boot time before other initiators are enabled. Alternatively, if run-time accesses to IODELAY are required then accesses to other peripherals on the L4_PER2 segment of the interconnect must be avoided while accessing IODELAY.

In order to support run-time SD-Card removal/detection on the MMC1 interface or other mode changes on MMCn interfaces, software should not modify IO Delay configuration when a new card is detected or speed is changed. However, limiting support of SD Card/MMC transfer modes to a common IODELAY configuration is an option. For example, the IODELAY configuration required for SDR50 is also compatible with identification, default-speed, high-speed, SDR12, and SDR25 transfer modes. Configuring IODELAY for SDR50 during boot without any further updates will avoid the hang condition and allows support all transfer modes up to SDR50. With this approach, the MMC1 interface cannot support DDR50 and SDR104 modes because IODELAY would need to be updated to support these transfer modes.

The final intended transfer mode may be known in advance when eMMC or other devices are attached to any MMCn interface. In that case, the appropriate IODELAY for the intended transfer mode may be configured at boot time (including HS200 mode if applicable).

Please Note: The standard Processor SDK software offering from TI (Linux and RTOS based) does not implement this workaround. Customers are expected to make the appropriate software modifications necessary to implement their own workaround when using this approach.

REVISIONS IMPACTED

SR 2.0, 1.1, 1.0

TDA2x: 2.0, 1.1, 1.0

DRA75x, DRA74x: 2.0, 1.1, 1.0