RT1170 SEMC wait pin

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT1170 SEMC wait pin

Jump to solution
393 Views
Eugene3
Contributor II

I'm using RT1170 on my board, and I connect SRAM device on SEMC.

When I use SEMC as ASYNC Mode with Wait Pin, how can I configure "Wait Assert Time" value?

Is it fixed at 3 clocks? 

Eugene3_0-1705551762426.png

 

0 Kudos
1 Solution
310 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @Eugene3,

I believe I understand your inquiry now. Thank you for the clarifications.

The Wait Assert Time is not configurable. It measures the time between the WAIT signal being asserted and the SEMC's sampling of the data from the SRAM. As you can see, once the data was sampled, the SEMC does not care about the WAIT signal.

This sampling is determined by the rxclkn, which is an internal signal that is used by the peripheral to sample the SRAM data. The diagram shows that as soon as the data was sampled, OE# is de-asserted. In other words, both the Wait Assert Time assertion and the de-assertion of OE# depend on rxclkn (which is not configurable and therefore neither are these signals in this case).

That said, we can consider that the time it takes for the SEMC to see the wait assert and sample the data (the Wait Assert Time) will be around 3 semc_clk cycles, yes. As soon as the data was sampled, the wait signal is irrelevant and the OE# will be de-asserted.

I hope this clears things up.

BR,
Edwin.

View solution in original post

0 Kudos
4 Replies
311 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @Eugene3,

I believe I understand your inquiry now. Thank you for the clarifications.

The Wait Assert Time is not configurable. It measures the time between the WAIT signal being asserted and the SEMC's sampling of the data from the SRAM. As you can see, once the data was sampled, the SEMC does not care about the WAIT signal.

This sampling is determined by the rxclkn, which is an internal signal that is used by the peripheral to sample the SRAM data. The diagram shows that as soon as the data was sampled, OE# is de-asserted. In other words, both the Wait Assert Time assertion and the de-assertion of OE# depend on rxclkn (which is not configurable and therefore neither are these signals in this case).

That said, we can consider that the time it takes for the SEMC to see the wait assert and sample the data (the Wait Assert Time) will be around 3 semc_clk cycles, yes. As soon as the data was sampled, the wait signal is irrelevant and the OE# will be de-asserted.

I hope this clears things up.

BR,
Edwin.

0 Kudos
269 Views
Eugene3
Contributor II

Thank you I understand.

0 Kudos
345 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @Eugene3,

As mentioned on this reply from my colleague on a similar community post, the WAIT signal is handled by the SRAM side, so please look into your SRAM's datasheet for information about how to configure the WAIT signal time to ensure assertion of the data. The Reference Manual only mentions the restriction that the wait valid time must be at least 2 semc_clk cycles.

BR,
Edwin.

0 Kudos
340 Views
Eugene3
Contributor II

Hi @EdwinHz 

I know the wait signal comes from SRAM side.

When will SEMC de-assert OE# pin after the wait pin is de-asserted by SRAM?

0 Kudos