SPRZ429N July 2014 – July 2024 AM5726 , AM5728 , AM5729
Access to IODELAY at Same Time as Other Peripheral on L4_PER2 Can Hang
Medium
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. The App Note SPRAC44 previously defined this requirement for all peripherals, except MMC/SD. However, restricting IODELAY configuration to boot time will pose data transfer speed limitations for the MMC/SD interface, since the IODELAY values need to change during real-time transfer speed changes. If the MMC/SD IODELAY is configured during run-time, the system may hang if other initiators are accessing peripherals on L4_PER2.
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, DCAN2.
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 configuration 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.
SR 2.0, 1.1
AM572x: 2.0, 1.1