Which QSPI flash would you choose for custom board?

[HP_it]

I'm banging my head against this one.

Initially I chose the W25Q128JV because it seemed like a suitable match for TouchGFX applications but it seems that the register layout is quite different from the (discontinued) Mircon part that is on the F746 board.

I've read somewhere that the Micron parts have better support but is there anyone out there that have had any luck with a custom board with QSPI flash implementation?

ANY help will be much appreciated!

[Tesla DeLorean]

Well the Winbond parts do take some effort because ST doesn't provide drivers (there being a relationship with fab/product with Micron/Intel and ST/Spansion)

The Micron parts do support DTR/DDR so bandwidth considerations there.

The 300mil SOIC16/SOP16 footprint has broadest compatibility/options.

The 1Gbit Winbond stacked device seems super unhelpful, and the NAND device doesn't support XIP

The W25Q256 and W25Q512 seems very similar, the driver for one seems to be working with the other. These devices need 4-byte addressing (ie >16MB)

Dual-Banking the devices takes some getting one's head around, but does improve throughput, obviously, and eats more pins.

Also have boards running with smaller ATMEL/Adesto parts in single/dual configuration, F7 and H7

ST doesn't sponsor any community work

[HP_it]

It just seems strange that the chip used on the Dev-kit is obsolete. I get that the life-time of memory devices is quite short since the fabs tend to make bigger and better all the time. But having no other standard design to turn to? It's not really helpful from ST side.

I saw your interesting work with timing the operations on the larger chips but I'm not really sure I can benefit from that. I'm quite focused on getting a TouchGFX system up and running but this QSPI is driving me up the wall.

I'm tempted to just roll with it and get a roll of the obsolete chips but it just makes my body cringe at the thought of designing a dead part into a new board.

Another headscratcher is that damn .stldr thing. I got a project compiling in the IAR kickstart edition (free code size limited compiler) and I think I got most of it right - but since I'm struggling with getting a reliable connection (even normal SPI is causing trouble) I might as well look for a better albeit more expensive solution.

I'm just curious if other people out there got anything like this to work?

[Tesla DeLorean]

The F746G-DISCO is a bit antiquated at this point, I'm sure when ST can't source any more N25Q128 parts they'll walk up the capacity ladder and provide new drivers, docs, etc. Either that or stop making the board, and moving to a newer alternative. The guys making the panel/touch will likely bore of making that too at some point.

Most of the more recent EVAL/DISCO either have a pair of 25QL512 parts, or the dual die 25TL01G parts.

The external flashing in IAR looks to be done with scripts, unlike Keil and ST which insist on compiled binaries and locking in clocks/pins. Given the combination of pin mapping it wouldn't have been that hard to build an automated tool. I ended up writing a tool last night to reconfigure/patch the pins in the F469I-DISCO loader automatically.

I think @Andreas Bolsch​  has an open/scripted approach to the loaders in OpenOCD

[Tesla DeLorean]

My issue generally with these flash parts is price/availability, having been burned on a number of occasions, I'd provide for as many options as possible.

If you have a couple of favoured parts consider putting down a dual-foot print of the SOP16 300mil / 7.5mm with a SOIC8 at 90 degrees inside the larger land-pattern.

Keep the signals relatively short and equally lengthen. Some of the these parts will happily clock at 100 MHz

Not sure how many pins your display uses, but perhaps look at the 100-pin H750VB device, it can support two QSPI, and has a lot of internal SRAM

Most of the QSPI circus is with the write/erase, not sure the application needs all this. Might need to consider if needing to do field updates.

The read/xip setup does take a little work, but I think one could probably code a library that could use the JEDEC READ ID and adapt sufficiently. Realistically over the life of a product you might expect to use several devices in production as availability and prices change, or new steps of the silicon add more/different features.

uBlox has long used QSPI memories, their approach was to keep all the chip specific stuff in a 4KB sector such that the ROM could boot-strap into the first few sectors, and then code selectively placed their by the update utility would manage the specifics of Winbond vs SST vs Macronix, etc.

[HP_it]

oh, that's a great suggestion. my current design is SOIC-8 and While swapping the package yesterday I managed to rip one of the pads :\

I will do another spin of the PCB in a few weeks so I will make a hybrid footprint for sure!

I'm running a 24-bit parallel LCD so about 30 wires - my application hinges on TouchGFX and H7 isn't supported yet.

I believe you're right, I don't need anything fancy for the application, the flash is purely for loading graphical assets during boot.

I've found a Macronix part, mx25l12833fm2i-10g, that looks like it has the same register definitions for QPI - the Winbond one sure did not!

I'm still not giving up hope that maybe I can find a part that could fit in with minimal changes

[HP_it]

Funny,

Macronix have even made a note on the similarities of the chips:

https://www.macronix.com/Lists/ApplicationNote/Attachments/1947/AN0244V1%20-%20Comparing%20Micron%20N25Q128A%20with%20Macronix%20MX25U12835F.pdf

strictly speaking it's not the mx25l12833fm2i-10g but the MX25U12835FM2I-10G which is a 1.8V device.. but I guess they are pretty similar!

[Tesla DeLorean]

Some vendors try to do that so they can be a "second source" for components. Some of the lower end commands/function are agreed at JEDEC. It is when you get into the more exotic commands and dummy cycles vs speed that the implementation details become important.

Here I'm using the 0x9F READ ID to pull manufacture/part data, and from that array size.

The 1.8V vs 3V stuff is likely with IO pin buffering and internal regulators, so yes often the same part/die, with some different bond-out options or configuration fuses.

In recent years there have been many merger, acquisition and consolidation in this space, as well as long term partnerships where designs/fabs are shared. JEDEC has been around for may decades to try and keep everything aligned and keep a reasonably common interface, and a sub-set of commands/functions everyone can agree on, before doing their own thing.

[HP_it]

makes good sense to try and use the same registers and definition all around the table.

I'm still a bit afraid to fiddle too much with the auto-generated code but that comes from a lazy point of view. Of course I should just get in and start developing the full driver and make that work - I'm just not used to work above 24MHz yet. Seems that is about to change really soon.

It seems that my path forward is clear at the moment - make a new board with better length of the wires for the QSPI (the CLK is severly shorter than the data wires for some stupid reason) Then I will get the new flash chip - the Macronix one and see if I can get that to talk to me. I hope this will work out..

[Andreas Bolsch]

Why do you think N25Q128 is discontinued at all? I'm pretty sure MT25QL128ABA is the very same chip except for the marking. N25Q128 is a former Numonyx device, after Micron aquired Numonyx they're probably just phasing out the old part *NAMES*. The device id of both devices is 0x20, 0xBA, 0x18. Same manufacturer id!

Although I didn't compare the datasheets in detail, it wouldn't be very sensible to sell a rather different device with same id to existing customers.

But anyway, it's certainly a good idea not to rely on any particular property of flash chips but only on 'standard' commands as far as possible. Regarding the footprint, I'd recommend to use SOIC16 *AND* WSON8 simultaneously (the latter apparently becoming more popular). If very particular properties (e. g. QE bit or drive strength) are used: In some cases these settings are non-volatile, so if set up by initial factory programming, there is no need to address these in the firmware. What's left (e.g. enter QPI-mode) is a rather limited set, by reading the device id it should be fairly simple to deal with a couple of different chips.

[HP_it]

well, would you look at that.. Thanks!

You're absolutely right!

The reason why I found myself stuck on this was due to the fact that the chip used on the F746-Disco board (N25Q128A13EF840E) is obsolete. Anything that resembles the N25Q128A is also not in stock. I haven't found the MT25QL128A mentioned anywhere, least of all on Microns site. It would be good practice to tell customers what chip to use when one is being removed from the manufacturing line.

Well, this solves my biggest headache so far! This chip is readily available! I still think I will have to rework my clock/data pin lengths to allow for the ca.100MHz operation speeds but that will be the least of my problems now :)

Thank you very much for pointing this (now obvious) fact out!