Details:

The affected SoCs includes two instances of ICSS (ICSS1 and ICSS2). There is a bus connection from ICSS1 to ICSS2 and from ICSS2 to ICSS1. This bus logic requires a synchronous reset (clocks to be enabled) to drive a known state on its outputs. If clocks are not enabled to ICSS1 in software, then depending on the random state of the ICSS1 output bus, it may continuously issue Read or Write transactions to ICSS2 resulting in corruption of the ICSS2 module. The same situation can happen in reverse if ICSS1 is enabled and ICSS2 clocks are not on.

The power-up state of the critical control signals on each bus tends to settle to 0-state, but that is not guaranteed without a proper reset. This is why the issue may not be observed on all systems or may have different fail modes from system to system.

Workaround(s):

If a single ICSS module is used in a customer system, then clocks to the other ICSS module should be enabled first – this results in the ICSS module that is being used having proper deasserted state on the input bus before it is enabled.

If both ICSS modules are used in a system, then software can use the EDMA controller to issue an atomic write to the clock enable registers such that the two ICSS modules clocks are turned on within 20ns of each other.

Pseudo-code for a system that uses only ICSS2 or ICSS1 is shown here:

// CM_L4PER2_PRUSS1_CLKCTRL and CM_L4PER2_PRUSS2_CLKCTRL

/* Example #1 if ICSS2 used (ICSS1 not used) */

// Enable ICSS1 clock – ICSS1 state may be corrupted as ICSS2 is powered off now

*(volatile uint32_t*)(0x4A009718) = 0x00000002;

// Enable ICSS2

*(volatile uint32_t*)(0x4A009720) = 0x00000002;

/* Example #2 if ICSS1 usage (ICSS2 not used) */

// Enable ICSS2 clock – ICSS2 state may be corrupted as ICSS1 is powered off now

*(volatile uint32_t*)(0x4A009720) = 0x00000002;

// Enable ICSS1

*(volatile uint32_t*)(0x4A009718) = 0x00000002;

If a system uses both ICSS1 and ICSS2, contact your TI representative for an SDK patch that implements the EDMA workaround.