TMDS64EVM: AM6421

Hi,

Huynh Nguyen said:

The question :"Is it true the WAIT will take precedent over the RDCYCLETIME or WRCYCLETIME when WAIT timing exceed the

CYCLE time ?" 

Yes - that's right. The assertion of WAIT (when wait monitoring is enabled) extends the RDCYCLETIME and WRCYCLETIME, and all other events like CSOFFTIME, etc.

Wait monitored as active freezes the CYCLETIME counter.

Refer to TRM section
General-Purpose Memory Controller (GPMC)
 - GPMC Functional Description
   - GPMC Address Decoder and Chip-Select Configuration
     - External Signals
      - WAIT Pin Monitoring Control 
        - Wait Monitoring During Asynchronous Read Access

Huynh Nguyen said:

Second question : "What will the GPMC bus behave when WAIT is stuck in assert condition forever or in the best case WAIT will

not de-assert for very long?"

If WAIT is asserted too long, eventually a time out error occurs.

In case of NAND reset, where WAIT is asserted for microseconds,

Refer to TRM section
General-Purpose Memory Controller (GPMC)
 - GPMC Functional Description
   - GPMC Address Decoder and Chip-Select Configuration
     - Error Handling

ERRORTIMEOUT: A time-out mechanism prevents the system from hanging. The start value of the
9-bit time-out counter is defined in the GPMC_TIMEOUT_CONTROL register and enabled with the
GPMC_TIMEOUT_CONTROL[0] TIMEOUTENABLE bit. When enabled, the counter starts at start-cycle time
until it reaches 0 and data is not responded to from memory, and then a time-out error occurs. When data are
sent from memory, this counter is reset to its start value. With multiple accesses (asynchronous page mode
or synchronous burst mode), the counter is reset to its start value for each data access within the burst.

Refer also to GPMC_TIMEOUT_CONTROL Register Field Descriptions

 - TIMEOUTSTARTVALUE - upto 511 GPMC FCLK Cycles

 - TIMEOUTENABLE

Regards.