AM3352: GPMC control using wait signal

Hi,

What software are you using?

Hi, I think this is Real time base OS. (Not TIRTOS). We connected FPGA board from AM335 EVM.

As you probably know, this is not supported by TI. Please clarify what support you expect from the BU, so that I can redirect this thread to the correct person.

Hi, This is not software issue. Sorry, my question was wrong words.
Actually, I edited original question.

Hi Champs,
Could you please follow this thread ?

Hi Mark,
Thank you very much for reply.
Actually, we don't need burst access. As I write it previous, we would like to extend GPMC_CLK out put during WAIT pin aseert at synchrous read/write.

<This is the reason>
We connect to FPGA from AM3352(Master).
Sometimes, FPGA read/write register access is kept waiting due to FPGA internal data competition.
So, we don't add additional wait time.

FPGA synchronize GPMC_CLK and process to register access. AM3352 have to continue GPMC_CLK output until FPGA inter process is ended.
So, we would like to synchronize WAIT signal start up with GPMC_CLK

So far , customer system is working as bellow .

We confirmed OE, CS,GPMC_CLK , data line output control using WAIT signal at single access setting (READMULTIPLE =0).

Can customer continue to use above method ?

Hi Kaz-san,

Yes, the GPMC_CLK should keep toggling after a synchronous transaction begins and it is stalled by the WAIT signal being active.

Between GPMC transactions the GPMC_CLK will stop. If the free-running GPMC_CLK is required to be actice and toggling outside of GPMC transactions, consider the AM57x devices, which can use an OBSCLK as a free-running GPMC_CLK. Its datasheet documents the skew between GPMC_CLK and OBSCLK to aid with timing closure. All synchronous inputs are latched with the GPMC_CLK.

Regards,
Mark

Hi Mark,

Sorry for multiple confirmation. Actually, I would like to confirm current customer setting if this is OK.

Customer system is able to continue GPMC_CLK ,data line , CS, OE output after WAIT control at Single access setting (READMULTIPLE=0).

Inspite of following TRM comment.

So, Can they continue to use this setting ?

--------------------------------------------------------------------------------------

「AM3352_Technical Reference Manual.pdf」P.614

7.1.2.3.8.3.4 Wait Monitoring During a Synchronous Read Access

• WAIT monitored as inactive unfreezes the CYCLETIME counter. For an access within a burst (when

the CYCLETIME counter is by definition in lock state), WAIT monitored as inactive completes the

current access time and starts the next access phase in the burst. The data bus is considered valid,

and data are captured during this clock cycle. In a single access or if this was the last access in a

multiple-access cycle, all signals are controlled according to their relative control timing value and the

CYCLETIME counter status.

--------------------------------------------------------------------------------------

<HW connection>

This connection is similar bellow picture. However, we don't connect these pins (gpmc_be0n_cle　/　gpmc_be1n　/　gpmc_wpn　/　gpmc_wait[1] ).

Register setting

Use CS1

Address             data.

0x50000090      0x3A601200

0x50000094      0x00070801

0x50000098      0x00020201

        0x5000009C      0x05830803

        0x500000A0      0x01070608

        0x500000A4      0x05030141

Hi Kaz-san,

I am not seeing any issue with the customer using Wait Monitoring During a Synchronous Read Access.
On a read, the WAIT signal will delay the effective ReadAccessTime (by freezing the cycle counter until WAIT is released)
On a write, the WAIT signal will delay the effective WriteAccessTime (by freezing the cycle counter until WAIT is released)
The clock will remain active during these delays.

Thanks for providing the GPMC registers. Based on their values, I was able to flag some GPMC Synchronous Timing Rule Violatons:

These rules can affect read and write reliability.

Refer to processors.wiki.ti.com/.../Tips_for_configuring_Sitara_GPMC_registers

Violations for Reads:
* CSRDOFFTIME < RDCYCLETIME

* Sync Read: Rule 3. (RDACCESSTIME – CLKACTIVATIONTIME) modulus (GPMCFCLKDIVIDER + 1) must be different from GPMCFCLKDIVIDER

* Sync Read: Rule 8. RdCycleTime must be strictly greater than all the Off times of the control signals (OeOffTime CsRdOffTime, CsWrOffTime, AdvRdOffTime, AdvWrOffTime, WeOffTime), plus the possible extra delays added (CSExtraDelay, AdvExtraDelay, WeExtraDelay, OeExtraDelay, CsExtraDelay).

Violations for Writes:
* CSWROFFTIME < WRCYCLETIME

* Sync Write: Rule 3. (WRACCESSTIME – CLKACTIVATIONTIME) modulus (GPMCFCLKDIVIDER + 1) must be different from GPMCFCLKDIVIDER

* Sync Write: Rule 6. If GPMCFCLKDIVIDER is greater than 0 and WAITWRITEMONITORING is enabled, WEOFFTIME must be greater or equal to WRACCESSTIME+2. If GPMCFCLKDIVIDER is 0 and WAITWRITEMONITORING is enabled, WEOFFTIME must be greater than or equal to WRACCESSTIME+1

* Sync Write: Rule 7. Regardless of WAITWRITEMONITORING and GPMCFCLKDIVIDER, WEOFFTIME and CSWROFFTIME must be greater than or equal to WRACCESSTIME+1

* Sync Write: Rule 8. WrCycleTime must be strictly greater than all the Off times of the control signals (OeOffTime CsRdOffTime, CsWrOffTime, AdvRdOffTime, AdvWrOffTime, WeOffTime), plus the possible extra delays added (CSExtraDelay, AdvExtraDelay, WeExtraDelay, OeExtraDelay, CsExtraDelay).

Regards,
Mark