QSPI - Clock starts before chip select is set

[Arnon]

Hi

I am using the QSPI to interface FPGA.

The setup includes STM32F769I-EVAL board wired to MAX10 evaluation board.

The QSPI is configured to indirect mode, data phase only. I was able to read data from the FPGA, control clock speed and set number of bytes to be read each time.

Among other issues, the problem I am facing is that sometime the clock would start while the Chip select is still high!

As the FPGA output a known pattern, it is clear that the CPU actually sample the data before the CS goes low.

The HAL_QSPI_Receive_DMA() function is used to trigger read, meaning that there is no control over the CS vs clock timing.

CCR register is 0x07000000 (Indirect read mode, data on 4 lines)

CR register is 0x40000f05:  DMA and interface enabled plus clock Prescalar and FiFo threshold configuration.

is this a known bug? There is nothing in errata sheet regarding indirect mode.

the attached pic- C1(yellow) is CS, while C2(purple) is clock. Both are CPU controlled.

*if anyone here consider using the QSPI as a simple quad SPI, do yourself a favor and reconsider…

[Andreas Bolsch]

You're totally right, there are indeed some pitfalls regarding the QSPI. But to be fair: The RM *explicitly* says it is intended for interfacing to serial flash ("The QUADSPI is a specialized communication interface targeting single, dual or quad SPI Flash memories.") as does the datasheet, and for this purpose, it works quite well. No promises for anything else. In particular, flash memory devices don't care about clock and data lines as long as they're not selected, so the problem you're facing is simply a don't care for serial flash.

[Arnon]

thanks @Andreas Bolsch​

"... flash memory devices don't care about clock and data lines as long as they're not selected" that's exactly my point - the CPU FW "thinks" X bytes are read while in reality, because the device is not selected, only X-1 bytes are read. the missing byte will be zeros or what ever the device outputs when its not selected.

[Andreas Bolsch]

Ah, so the problem is not literally early start of clock, but missing clock cycles during CS being active?! You might try to add some dummy cycles before data phase. Of course, this means you have to adapt the FPGA design accordingly ...

The RM says "In order to assure enough 'turn-around' time for changing the data signals from output mode to input mode, there must be at least one dummy cycle when using dual or quad mode to receive data from the Flash memory." Although you don't have instruction nor address phase, it's quite possible this requirement is inherently used in the internal design of the QSPI.

[Arnon]

thank for the suggestion @Andreas Bolsch​ 

Since the CPU just read data from the FPGA, no "turn around" time should be needed as the data is always "input"

Adding dummy cycles - that also was my line of thought, so good idea :)

The problem with adding dummy cycles is that the number of missed clocks is not constant!

I found out that CS falling edge to clock rising edge time gap is proportional to the QSPI clock speed. For example, less than 1 Mhz, it is still ok, that is the CS is set before the clock starts. with clock speed of ~2Mhz, there is one clock missed (half a byte) with clock speeds of 3Mhz or more, 2 clocks are missed(whole byte). This happens with or without dummy cycles. I am not sure if at given clock speed the missed number of clocks is constant or there are other factors.

My point is , since the I can't trust the number of missed clocks to be consist, it is impossible to know how many dummy cycles to set. Not to mentioned the throughput loss.

I will try to use additional GPIO as a CS: set GPIO, perform read, on the callback release the GPIO.

If you have any other ideas, I'll be glad to hear...

thanks!

--Arnon