AM6442: CSRDOFFTIME and CSWROFFTIME specifications

Part Number: AM6442

In the AM64x technical reference manual it states
   

and gives this graph for clarity.

 

Looking over the register setting, this would mean that CS will go high after what is set in the various bit fields and cannot be longer than 31 GPMC clock cycles from the start cycle time.
   

When I run the GPMC with these various register setting the CS off time is much longer than 32 clock cycles. Is the documentation wrong on what CS off time is?

  • Hello Nathan,

    Thank you for your query !

    My understanding is that you are asking about CSRDOFFTIME0 (GPMC controller multiple data read operation) which should NOT exceed 31 GPMC_FCLK clock periods, correct ?

    From your logic analyzer diagram I see that the number of  GPMC_FCLK cycles from start access time, that should be BE0n_CLE going Active LOW to the moment when OEn is sampled low on rising GPMC_FCLK edgeis CSRDOFFTIME0 = 12 cycles which is less than the max of 31 cycles. But I may not be considering something. Are you counting any redundant cycles ?

    Q3. Why are the BE0n_CLE, BE1n and BE2n constantly kept LOW (constantly asserted) ? 

    Q4. Is there some WAIT signal involved in your setup ?

    Please help me understand ?

      

    Checking vs definitions:

    The exported GPMC_CONFIG2_i[31:0]=0x10001 value means GPMC_CONFIG2_i[12:8] CSRDOFFTIME =0 does NOT much the number of the oscillogram shown CSRDOFFTIME cycles.

    Looking forward to your feedback.

    Thanks

    Kind Regards

    Anastas Yordanov

  • Hi Anastas,

    My questions: From reading the technical reference manual of the AM64x, the CS__OFFTIME is measured from the start of transaction, or the start of the GPMC clock when running in synchronous mode (section 12.3.3.4.8.2). This would mean that the nCS_ line can not be logic lower longer than 31 GPMC clock cycles (limited by the value of register GPMC_CONFIG2_0).

    But in my testing, when I set CS__OFFTIME to 0 the nCS_ line will be low longer than 31 GPMC clock cycles. Why is that?

    Q2.) Are you counting any redundant cycles?

    A2.) No

    Q3.) Why are the BE0n_CLE, BE1n and BE2n constantly kept LOW (constantly asserted) ? 

    A3.)Some of the signals where not connected when I did my logic analyzer connection and why some were always logic low.

    Q4.)Is there some WAIT signal involved in your setup ?

    A5.) No

    As you stated in your last statement, "The exported GPMC_CONFIG2_i[31:0]=0x10001 value means GPMC_CONFIG2_i[12:8] CSRDOFFTIME =0 does NOT much the number of the oscillogram shown CSRDOFFTIME cycles", is why I am confused.

    IF CS__OFFTIME is a value greater than 0, then the statement in the technical reference manual makes sense as seen in the picture below (CS line is the top line)

    CSWROFFTIME = 15

    CSWROFFTIME = 1

    But when CSWROFFTIME = CSONTIME or when CS__OFFTIME = 0 you get the following output

    CSWROFFTIME = CSONTIME or when CS__OFFTIME = 0

    Which does not follow my understanding of the technical reference manual. Because of what I have seen when CS__OFFTIME = 0, or when CS__OFFTIME = CSONTIME not following what the technical reference manual states, I wanted clarification if the AM64x I have is defective or this is expected behavior that is not well documented.

    Regards,

    -n8

  • Hi Nate,

    The TRM states "When RDACCESSTIME completes, control signal timings are frozen during the multiple data transactions, corresponding to PAGEBURSTACCESSTIME multiplied by the number of remaining data transactions."

    Basically the counter from start of cycle freezes during the burst, so you have at most 32 cycles + # cycles required by the burst.
    You can prove this by disabling READMULTIPLE or playing with ATTACHEDDEVICEPAGELENGTH and observing CS.
    If you need even more cycles you can double the ON/OFF times by setting TIMEPARAGRANULARITY.

    Regards,
    Mark