Which QSPI flash would you choose for custom board?

[HP]

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]

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]

I like your metaphors! You're absolutely right. I've been away from the hardware development stuff for the last 2-3 years so this project is my 'gateway drug' back to the fun stuff. And it is - when you get something to work. the LCD interface (where you helped a lot with your comments!) and the SDRAM interface are two big successes.

I will carry rope and lunch from now on :D

[HP]

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]

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!