AM6421: Read problem while GPMC working at 133M clock

Snapshot of D0 and D1 pin by oscilloscope for GPMC clock '15M' and '133M'are here:

Hi enny Zhou,

Thanks for your query.

Not clear which core and OS are you working on ?

Regards

Ashwani

Hi Ashwani,

I work on A53 core, however it's the DMA who does the data transmission via GPMC.

Also, I'm using this SDK 'mcu_plus_sdk_am64x_10_00_00_20', it's 'freeRTOS'.

Jenny Zhou said:

I work on A53 core

Means, this is A53 running FreeRTOS + application using DMA + GPMC ?

Regards

Ashwani

Yes.

Hi Ashwani ,

is there any update of this issue?

First thing, I want to make sure is that 'rdAccessTime = 2' means the access time is the 'red line' in this image, right?

Hello Jenny,

I assume that you have not changed any GPMC timing parameters in the syscfg.

So, all the timing parameters that are available in the syscfg are supported for asynchronous NAND devices and PSRAM Asynchronous and not for synchronous NOR.

In your case, you interfaced with FPGA as NOR with synchronous type and timing parameters belongs to either NAND or PSRAM memory.

This could be the problem. Now, to work for the GPMC NOR synchronous at 133 MHz clock we need to be tuned the GPMC timing parameters according to NOR memory.

Please share the GPMC DMA project as well to review your code, because we don't support GPMC DMA in MCU+SDK.

Support 1 : Tune Timing parameters to NOR Synchronous memory 

Support 2 : Review the GPMC DMA Application Project.

I am routing your query to Hw expert for support 1, and I can review your GPMC DMA application.

Regards,

Anil.

Hi Swargam,

I did change the GPMC timing parameters in syscfg to suit for the synchronous NOR.

also, I pinMode set the GPMC_FCLK pin to synchronously generate a clock to FPGA.

I attached the 'syscfg' and all generated config files, please review.

A key timing parameter is the ''rdAccessTime', would you help to make sure this is the exact place with my setting?

thanks for involve the HW expert for support 1, I want to make sure you would tune the data read exactly to 'rdAccessTime=2' with 133MHz, right?

look forward for you response, it's an urgent problem, which currently block our project.

Jenny zhou

Hello Jenny Zhou,

I have already routed your query to Hw experts and I will send mail as well.

Meantime, you can try the PSRAM Timing settings for your use case and see still you are getting an issues or not.

Regards,

Anil.

Hi Anil,

I've already change the Timing setting, which suppose suit for my FPGA RAM, I attached files here, you can take an eye on 'ti_drivers_config.c'2262.Board.zip

Hi All,

Is there any update of this issue?

Hi Anil,

Is there any update of this issue? Have you reviewed my Timing setting? Is there anything wrong?

When can I get the update?

Our project is very urgent and depends on this issue, we expected issue solved by this week 2/7.

Hi Anil,

I have a new founding, there's 'switching characteristics' of GPMC pins, so almost all pins can be delayed.

so if GPMC_OE delayed, even rdAccessTime=2, which mean even data is not sampled exactly at middle of OE, may before a little time, right?

Hi Jenny,

Apologize for the delay.

Timing analysis of the 133M waveform shows a setup time marginality.
133MHz has a period of 7.5ns. From the waveform it appears rise/fall time of the data signals is ~3ns. This leaves less than 4.5ns of setup time at the pins (not counting fall time of OEn or turnaround time in FPGA which appears small in this condition).

However, in GPMC async mode the clock that latches data is internal to the core (GPMC functional clock). The delay through IO buffer further subtracts from the data setup time. Increasing READACCESTIME from 2 to 3 provides 7.5ns more setup time at 133MHz (and takes 7.5ns from hold time).

Another way to get more setup time is to change OEONTIME to 1 CLK or 1/2 CLK cycle earlier. This can be achieved with OEONTIME = 0 (1CLK cycle) or OEONTIME with OEEXTRADELAY = 1 (1/2 CLK cycle). This assumes the FPGA can accept OEn 1/2 cycle after CSn goes falling edge.

And yet another way to get more setup time is to slow the clock frequency down as you have observed.

Above approaches may resolve the setup time marginality, but they do not account for variable delay through IO buffer for data before it is latched by the internal GPMC functional clock. TI needs to resolve this uncertainty in the datasheet for async mode.

An alternate way to latch the data is to configure for synchronous reads (READTYPE = 1) even though the CLK is not actually used to latch the control signals. The benefit of using synch mode is that the CLK that is used to latch data loops back from an output IO buffer in through an input IO buffer (clock loopback). So CLK is delayed through the output buffer and delayed again going through its input buffer. The output delay is about the same as OEn and the input delay is about the same as the data going through their IO buffers. Even more beneficial is that the datasheet setup and hold timings (F12, F13) can be checked against the free-running GPMC0_CLK to ensure setup and hold time are satisfied.

The datasheet variability of CLK to OE (F10, F11) does make closing timings at 133MHz more difficult, but I believe this datasheet parameter is overly pessimistic. However, to make the system work with this timing variability I again recommend launching OEn 1/2 CLK cycle earlier. Set READTYPE = 1 for sync reads. Change OEONTIME to 0 with OEEXTRADELAY set to 1. Keep RDACCESSTIME at 2.

Work the timing analysis.

You can try the above approaches and let us know the results. The preferred method is the final synchronous option.

Regards,
Mark

Hi Mark,

Thanks for your comments.

Here's some comments and update:

1. My setting is 'sync mode' not 'async mode', Here's the whole setting, for detail you can refer to 'ti_drivers_config.c' file from my previous sharing.

'{

.gpmcBaseAddr = CSL_GPMC0_CFG_BASE,
.dataBaseAddr = CSL_GPMC0_DATA_BASE,
.elmBaseAddr = CSL_ELM0_BASE,
.inputClkFreq = 133333333U,
.intrNum = 138,
.intrPriority = 4U,
.chipSelBaseAddr = 1342177280U,
.chipSelAddrSize = GPMC_CS_MASK_ADDR_SIZE_16MB,
.clkDivider = CSL_GPMC_CONFIG1_GPMCFCLKDIVIDER_DIVBY1,
.waitPinNum = CSL_GPMC_CONFIG1_WAITPINSELECT_W0,
.addrDataMux = CSL_GPMC_CONFIG1_MUXADDDATA_NONMUX,
.timeLatency = CSL_GPMC_CONFIG1_TIMEPARAGRANULARITY_X1,
.waitPinPol = CSL_GPMC_CONFIG_WAIT0PINPOLARITY_W0ACTIVEL,
.readType = CSL_GPMC_CONFIG1_READTYPE_RDSYNC,
.writeType = CSL_GPMC_CONFIG1_WRITETYPE_WRSYNC,
.timingParams =
{
.csOnTime = 0U,
.csRdOffTime = 4U,
.csWrOffTime = 4U,
.advOnTime = 0U,
.advRdOffTime = 1U,
.advWrOffTime = 1U,
.advAadMuxOnTime = 1U,
.advAadMuxRdOffTime = 2U,
.advAadMuxWrOffTime = 2U,
.weOnTtime = 1U,
.weOffTime = 3U,
.oeOnTime = 1U,
.oeOffTime = 3U,
.oeAadMuxOnTime = 1U,
.oeAadMuxOffTime = 2U,
.pageBurstAccess = 0U,
.rdAccessTime = 3U,
.wrAcessTime = 2U,
.rdCycleTime = 4U,
.wrCycleTime = 4U,
.wrDataOnMuxBusTime = 0U,
.cycle2CycleDelay = 0U,
.busTurnAroundTime = 0U,
.cycleDelaySameChipSel = CSL_GPMC_CONFIG6_CYCLE2CYCLESAMECSEN_NOC2CDELAY,
.cycleDelayDiffChipSel = CSL_GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN_NOC2CDELAY,
},

2. I've tried your suggestions as below, but got no change.

'Change OEONTIME to 0 with OEEXTRADELAY set to 1. Keep RDACCESSTIME at 2'

3. Our FPGA's behavior is that data comes out at next clock after 'GPMC_CS' is asserted. That is '1', starts from 'csOnTime', 'start of the cycle' as well.

Though having setup time, waveform shows at '2', data has already been stable. So if 'rdAccessTime=2', we should get correct data.

4. Could you confirm that in 'sync mode', GPMC did 'read' data at '2'nd clock start from a read cycle if I set 'rdAccessTime=2'? or there'll be some advance or delay? and the what would be it?

Hi Mark,

Is there any more update of this issue?

Can I come to conclusion: 

Even in sync mode, since there's internal delay(setup time) between 'rdAccessTime' and 'actual time of getting data', we need expand the access point from '2' to '3' to suit for GPMC controller's setup time, event though waveform shows data already stable at '2'. 

right?

Hi Jenny,

OK thanks for clarifying that the FPGA launches data on first clock rise edge after clock rise edge where CS is low. That explains why OEn 1/2 cycle earlier did not change anything.

I agree after looking at the waveforms that the data setup time of 1.12ns should be satisfied.
 - It would help if the CLK was also probed.
 - Are the signals probed very close to the SOC pins?
 - Can you share another waveform at 133MHz - capture CLK, CS, and one of the bits that is frequently captured incorrectly - like Data[1] or Data[5]

Can you please also provide a dump of the hexadecimal contents of the GPMC registers, where n below is the chip select being used?
 - GPMC_CONFIG1_n
 - GPMC_CONFIG2_n
 - GPMC_CONFIG3_n
 - GPMC_CONFIG4_n
 - GPMC_CONFIG5_n
 - GPMC_CONFIG6_n
 - GPMC_CONFIG7_n

Specifically, I want to know if the WAITREADMONITORING bit is set. And if it is set, what is the behavior if it is cleared?

My hope is to either prove there is a setup time violation, or to get the data latched correctly with ReadAccessTime = 2.

One other experiment is to see if you can delay CS 1/2 cycle and reliably capture data with ReadAccessTime = 3. Simply make CSEXTRADELAY = 1 with ReadAccessTime = 3. This may be necessary to work robustly with the full range of variability of CLK to CSn (F2, F3). The delay from CLK to CS may be different on devices received in the future. They might not behave exactly like the device you have been testing. They may be at either ends of the datasheet parameter and you should to program the GPMC timings to work for both extremes.

Regards,
Mark

Hi Mark,

this waveform has already had 'D1', besides 'D0'.

Here's the dump of the hexadecimal contents of the GPMC registers, and I see ''WAITREADMONITORING' has not been set.

And I've tried the 'CSEXTRADELAY = 1 with ReadAccessTime = 3', yes, data can be read correctly. As my understanding as long as 'ReadAccessTime = 3', no matter 'CSEXTRADELAY = 1 or 0', data can be read correctly.

Hi Jenny,

Jenny Zhou said:

And I've tried the 'CSEXTRADELAY = 1 with ReadAccessTime = 3', yes, data can be read correctly. As my understanding as long as 'ReadAccessTime = 3', no matter 'CSEXTRADELAY = 1 or 0', data can be read correctly.

I recommend keeping CSEXTRADELAY = 1 with ReadAccessTime = 3. These timings are more compliant with the full range of variability of CLK to CSn (F2, F3).

Thanks for confirming the configuration works.

Regards,
Mark