AM3517/05 GPMC synchronous read with wait enable not working

Hi Biser,

Thanks for the reply.  Yes I do have it enabled.  I should also mention that I have already got the synchronous read/write working without the wait enable feature.   I am interfacing with an FPGA, and would like the FPGA to control how long a read access would take as this time would grow as we add more and more registers/memory to the FPGA.  I figured the wait signal feature would be perfect for this, but could not get it to work for some reason. 

Donald

Hi Biser,

./pp -w 0x6e000050 0x00000000

I am using WAIT1, active low.  Reading 0x6e000054 initially gives 0x00000301, which is also confirmed using scope probing.

Donald

Hi Biser,

I have checked my setting many times and not sure what is wrong.  Can you elaborate which part doesn't seem right to you?  I am running synchronous multiplexed single read and write, with wait monitoring enabled on the read. 

Do you think you could answer some of my previous questions?

1) Is there a timing requirement on when wait has to be asserted?  Various timing diagram in the tech manual show it asserted at different times, when CS is asserted, when ADV is asserted, etc.  My understanding is that it can be asserted anytime before rdaccesstime is up, and when it does it should freeze the access indefinitely until it is deasserted when valid data is available, is this correct?

2) Related to 1).  While wait is being asserted and read cycle in being frozen, I expected the gpmc_clk to continue to run indefinitely so that the device could drive back the wait deasseration on the rising edge of gpmc_clk, being this is a synchronous interface.  I don't see that happening on my scope.  I see the clock going away in the middle of my wait asseration, thus causing the wait to unable to deassert due to the gpmc_clk is no longer there.  Is my expectation correct?

3) I am getting a seg fault while trying to do the read access with wait.  I don't how to interpret the dump from the seg fault to give me some clues what is wrong with it, any suggestions on that?

Most troubling thing is I don't understand why I am getting seg faults when I try to use the wait feature.  Once that happens access to another other registers in the SBC, even those outside of the GPMC range will result in seg faults, the only thing to do that that point is to power cycle the board, which is really not an acceptable behavior. 

Thanks

Donald

Hi Biser,

You mentioned WAIT is an external asynchronous signal to the AM35X.  Is this true regardless whether if the GPMC interface is set to synchronous or asynchronous mode?   The datasheet list a 3.782 ns setup time and 3.343 hold time (F21 and F22) for the wait signal relative to gpmc_clk, what does this mean if wait is treated as asynchronous?  What would happen if these timing parameters are violated when the interface is setup for synchronous access?  Would that cause metastability issue that could cause a seg fault, or would it simply cause the wait to be valid one cycle later?  My gpmc_clk is running at 84 MHz right now, so 7 ns of my 12 ns period is the setup and hold time requirement, which doesn't leave me much time to propagate the clock to the device and wait signal back from the device.  

I am going through the app note you sent me right now.

Thanks

Donald

Hi Biser,

I think I figured out what my problem was.  I had a mistake in my gpmc configuration which caused the rdcycletime to end prematurely.  After I extended rdcycletime things started working right away. 

I am still curious about the wait signal timing.  As I am pretty sure I am violating the signal's setup and hold time right now but I think it should be ok if the am35x treats that signal as an external asynchronous signal.  I am ok with the wait signal get deasserted one or two cycles late as the readback data will already be valid on the bus by then. 

Thanks

Donald