QSSI-High Speed Clock Operation

BIPIN BHATT said:

due to very high propagation delay, RX data from slave looses synchronization with clock.

May I agree w/vendor's Amit - that such "high propagation delay" is your - not the MCU's - responsibility.

That said - would not that same, "high propagation delay" visit your TX data?   If not - might an unwanted capacitance or other component, "sit on that signal trace/MCU pin" - and cause that delay?   As always - would it not prove useful to "swap" that SPI-based IC - with another (fresh) one?

You've provided no information regarding your MCU board and/or its routing/connection to the flash device.   Long leads, breadboard-like construction & even marginal power levels - any/all may account for the issue you report.

I'd place much trust in the MCU & Flash vendors  - the implementation/connection between those two - not so much!

BIPIN BHATT said:

is affecting Tx data as well but for that clock is also equally delayed so they are in sync. 

As all signals: clock, data (TX & RX), & chip select all must pass through the level translator - I cannot grasp how this impacts RX data alone.   (does not that translator provide, "equal delay" between all signals - which pass thru & are translated?)   [although - there "may" be a direction difference when "up converting" signal levels...i.e. "only" the RX data - which leaves the QSSI @ 1V2 levels - must be, "up converted" (in level)]

Should that prove the case - I first thought (para just below) - which upon reread I now believe mistaken!

Should that "direction" result in your propagation delay - cannot you "level shift" (down) the clock - so that it must undergo the same, "up convert" as RX Data?   This may require different circuit configuration so that the level translator presents "identical" delays - in either direction.    (one wonders if a "more equalized" delay device exists - saving you from the effort to "tweak" each signal path...)

***Dawns now that the MCU "reads" incoming data on its own clock edge - and there is "nothing" we can do to "delay" that read as it is (likely) routed & handled internally by the MCU.   In this case - I fear that you're "stuck!"

Might you link to the QSSI data sheet - so that we can determine if, "prop delay" indeed bears such directional "sensitivity."    (stinks if that's true...)

That's well answered & explained - thank you - appreciated.

Agree that when transmitting - and if (indeed) clock & data undergo identical delays - that data should arrive (bit later) but fully, "Sync intact."

And - as you nicely noted - when operating in "reverse (reading the SPI device) that RX Data may be (almost) 2x delayed.   (I sense that there "might" be some (slight) overlap of the clock's arrival at your QSSI device and its output upon RX.)

Is not the cause of this (clearly) the forced voltage translation?    And - if that's the case - how long/hard have you searched for a suitable QSSI device which works at - or closer - to 3V3?   That search appears central to the quickest, easiest remedy to this interesting issue - which you've neatly identified & posted.

My "attention-deficit" labeled brain may have arrived at a solution - although hardly a neat/clean one.

As the issue arises due to your delayed RX data in combination with our inability to delay the SPI clock - can/t we feed that same "initial" RX Data bit (the one which appears to be consistently "lost") into a simple latch @ the QSSI device? 

We then can "later" read this (currently lost) first RX Data bit - and logically assemble it into the 7 bits of (otherwise) valid SPI data.   I envision this being done via direct connection to a "free" MCU GPIO port bit configured as input.   (note - neither our esteemed "House Speaker" nor this cb1 "solution" escape "messy.")

Hi Amit,

I did not see your (above) post.

To your point re: MCU "reading SPI data" my 06:58 post earlier today:

"***Dawns now that the MCU "reads" incoming data on its own clock edge - and there is "nothing" we can do to "delay" that read as it is (likely) routed & handled internally by the MCU.   In this case - I fear that you're "stuck!" ... indeed shows my recognition of this issue...

If I'm correct in noting that poster claims to "correctly" receive "all bits but the first one" - my 09:38 posting may have some value.    (Or not - fast/furious trumps full thought/consideration...)

I'd add one more point - if indeed the QSSI market (now) predominates in (other) than 3V3 voltage levels - should not your MCU - when configured into that mode - adapt to & accommodate those lowered voltages?    (apologize if this constitutes blasphemy)

But he (more recently - @ 03:04 today) wrote: I am writing 16-bit data 0xAAAA and receiving the data 0x5555.  

That unique bit pattern suggests - at least to me - that this may be a, "Single Bit" error - which is far more precise than, "not correct."

And - which may be corrected as my post detailed...

Yet still - should not the MCU adapt to & accommodate such "recognized" QSSI demands?    That is the "point" of QSSI - is it not?

Hi Amit,

Yes - such (optional & programmable) delay of the RX Data MCU read is one solution.

Yet still - that does not escape the requirement for the "cost/size/placement & routing" of the voltage translator.

Best would be the ability of the MCU to "directly accept & generate" COMPATIBLE voltage levels to the QSSI device(s).  (escaping any need for translators!)

Note: so "easy" for we outside/bomb-throwers - not so much for those tasked to, 'Do the job..."

As some have said (even here) "Devil is in such details."

Frustrating ALL (the present result) may not trump (frustrating those few) who do not attend to the details...

Hi cb1,

Thanks for all your help and support.

Also your suggestion about logical merging of 7-bit with first bit can work in current situation.

But its not reliable as 7-bit received from QSSI may not be right in every situation as my timing is very marginal so small deviation in propagation delay or environment condition will result in wrong data received by QSSI.

Hi Amit,

The permanent solution given by cb1 to provide separate IO voltage rail will be really helpful me and many.

Or supporting slave communication at higher data rate will also solve the problem caused by propagation delays.

Regards,

Bipin

BIPIN BHATT said:

The permanent solution given by cb1 to provide separate IO voltage rail will be really helpful me and many.  

Mais certainement mon ami - mais certainement.   

On occasion - this emperor's clothes - may not meet their (usually expected) high standards.    (despite his - well skilled - "tailor's" protest...)

In the interest of (somewhat) assisting & lightening the workload upon my friend, Amit - the following is presented.    This from poster's Voltage Translator IC's data-sheet:

What may have been missed - yet may be of critical importance - is the choice of VCCB to tie to the MCU's 3V3 supply.   Then the QSSI device ties to VCCA - which poster lists as 1V2.   Under those conditions - the "middle row" of the above, "Prop. Delay" chart applies.   Yet - if we could some way/how "up" that QSSI device to 1V8 power (from 1V2) - the propagation delay cuts in half!   (i.e. decreases from 7 to 3.5nS.)  

Even more critical is that the 1V2 supply to the QSSI is "stiff" - suffers no drop out - under any conditions!   For instance - if VCCA "drops" to 1.1V the propagation delay may "balloon" to ~20/3 = 6.7 + 7 = 13.7nS!

I'd expect that use of a QSSI IC which accepts 1V8 rather than 1V2 very well may "meet" your timing specifications.

And - best of all - if you could find a QSSI device accepting ~3V3 - no translator would be required!

Hi Amit,

With slave mode I can feed back delayed clock with RX data for capturing the data on another SSI port.
In this case clock and Rx data will be in sync so correct data will be received.
I have already tested this configuration but working only up to 10MHz.

Regards,
Bipin

BIPIN BHATT said:

You and Amit can suggest me some other level translator parts

Well - perhaps we could - but that's wandering outside the central purpose of an MCU forum - is it not?   And may well deprive you of the investigative skills so necessary to lead you to even further success!   I cannot speak for Amit - but I pass.

As an experiment - not intended for production - and in absence of your more detailed investigation - how much "head-room" remains between 1V2 and the absolute max for your QSSI device?   Sometimes - but not always - a 5% "boost" above the "idealized/specified" IC operating conditions "may be" acceptable.   And - as we "break" from that 1V2 limit the device's "propagation" performance should improve.  

That said - you (and any/all others) do this entirely at your own risk - and only after careful examination of your device spec - and then consultation (and the blessing) from your device's vendor.   (note the legal boilerplate - bottom of this forum - vendor's "Blake" added such at my request - years past...myself/other outsiders are, "Providers of Content")

As your MCU is limited to 3V3 @ QSSI - your investigation should (likely) begin at that voltage level - and descend slowly to avoid a "repeat" of the conditions you've posted...

cb1_mobile said:

As your MCU is limited to 3V3 @ QSSI - your investigation should (likely) begin at that voltage level - and descend slowly

Hi Amit,

Believe we've come to the identical conclusion.   

Dawns that poster can serve himself - repay your kindness - and prove beneficial to many others here by searching/finding - then presenting those QSSI devices which are 3V3 compatible.

I need to wake up this thread.   I'm having the same problem, and I see that this thread correctly go sidetracked into a board design discussion.

I have to access my SPI devices though a level shifter, and the propagation delay limits my data rate.

On my system, I get decent results at 10MHz, but I'm getting occasional ( once in a few million reads) bit errors.   

I have tried the High speed clock mode in the hopes of getting a little more timing margin, but it completely breaks my transfer.  

The data sheet isn't very helpful.    How do I enable this?   The data sheet implies that I just set the HSCLKEN bit after enabling the interface, but that doesn't work.  Is there more that I need to do?