STM32F746 QSPI strange behavior

[Eugene Solo]

Posted on August 22, 2017 at 04:23

I'm experiencing strange behavior of QSPI peripheral (or may be flash chip itself -- N25Q128 in SO8; chips are not shiny new, but never used; datasheet Rev. 8 July 2014): despite what is stored in NVCR/VCR registers, number of dummy cycles is 10. Chip is 'fresh' from reel, datasheet says that chips are coming with  NVCR factory preprogrammed to 15 dummy cycles (0b1111) for maximum compatibility and maximum clock speed (108MHz). I've checked it - yes, NVCR is 0xFFFF (all '1's) as in datasheet, same as VCR.

And then...

Quad Command Fast Read (QCFR) has that dummy phase, so I'm writing 0xF to QUADSPI->CCR.DCYC and expecting that i will get my data intact. But instead of this i see that data output is somehow shifted in time for some fixed number of clocks, independent of clock frequency (I've checked this on 108MHz and 1MHz, even with maximum prescaler factor). By using empirical approach I've found that actual number of dummy cycles is not 15, but 10! Strangely enough, datasheet' illustration for Quad Command Fast Read shows 10 dummy cycles.

When i've discovered actual number of DCYCs, i've re-tested code on maximum clock speed and it worked flawlessly - DMA writes, DMA reads, everything looks fine.

So this is my question: how can I pre-determine number of dummy clocks without experimental evaluation? Is this 'dummy cycle' same thing in ST and Numonyx documentation? Where I've lost 5 cycles? Is this hardware quirk or just my misunderstanding?

#stm32f746 #qspi #quadspi

[Amel NASRI]

Posted on August 22, 2017 at 12:07

Hi

Solotchin.Eugene

‌,

The number of dummy cycles depends on the memory you are interfacing using the QSPI.

The number of dummy cycles should be configured in the QSPI memory according to the operating clock speed, for that, the user should refer to the memory device’s datasheet.

This is what we explain in

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/b0/7e/46/a8/5e/c1/48/01/DM00227538/files/DM002275pdf/jcr:content/translations/en.DM002275pdf

: 'Quad-SPI (QSPI) interface on STM32 microcontrollers'.

-Amel

[Eugene Solo]

Posted on August 22, 2017 at 13:07

Yes, and that is exactly what i did. According to N25Q126 datasheet, 15 clock cycles is default value (check), factory pre-programmed in NVCR (check), loaded upon POR into VCR (check) and it is good enough for any operating speed, from lowest to highest (check).

I'm looking in datasheet for that specific memory chip and I see value of 0b1111.

I'm writing this value to DCYC.

I'm expecting that it should work as intended.

But it is not.

Anything else is working fine, but not this.

So, how exactly should I determine exact value to be written in DCYC, if datasheet gives wrong/vague/not-so-correct explanation about it?

[Amel NASRI]

Posted on August 22, 2017 at 18:07

Based on

https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128_3_volt_with_boot_sector.pdf

 and precisely the table 4,  the highest dummy clock number is 10 to ensure an optimized fast read instructions performance.

This is what we already configure for the examples provided in the STM32CubeF7 package for the STM32746G-Discovery which is using the  N25Q128A.

-Amel

[Eugene Solo]

Posted on August 22, 2017 at 18:41

and table 3 shows default values, pre-programmed and loaded on startup. 10 is not really 'maximum allowed', its may be more or less optimal value. What I can't get is why default value (and loaded on reset in every register which can contain it) is not really valid when it *must* be acceptable and 100% safe to use it.

[Amel NASRI]

Posted on August 23, 2017 at 10:19

May be this has to be checked with the manufacturer of the interfaced flash memory.

-Amel

[Eugene Solo · Accepted solution]

Posted on August 24, 2017 at 16:19

Anyway, I'm happy to report that FatFs successfully started on QUADSPI bus.

I'm using 

http://elm-chan.org/fsw/ff/arc/ff13.zip

with some minor adjustments (slightly modified diskio.c) and 'hand-made' QSPI driver with very basic caching -- and without CubeMX.

To be correct, 1st time i've tested QSPI with help of u-boot, but almost without any understanding of how it works.

Then I've tried CubeMX and results were slightly below acceptable level (functionality is buried below complexity, it's just too deep to comprehend).

And then I've studied datasheets and appnotes.

Wrote my code for initialization, control and DMA transfers.

Checked how FatFs works with primitive 'ramdrive' (simply a pointer to somewhere in SDRAM).

Wrote my own set of glue functions and found that without cache that would be nearly impossible to use QUADSPI flash as read/write drive with random access.

And finally got it working.