W25Q256 breakout for Teensy 4.1

JotaEfe13

Well-known member
Hi, guys.

I want to use a W25Q256 SOIC16 flash ship with the Teensy 4.1 and I thought I could try making a breakout. The idea is similar to the one of this post, but in my case, with the Teensy 4.1 and without using the Audio Board.


This is the pinout of the IC:
w25q256.PNG


My idea is to use these pins on the Teensy 4.1:

t4.1.png


The mapping would be the following:
Code:
Pins 1, 2 ,3 and 9 of the W25Q256 go to 3.3V. I have added a decoupling capacitor of 0.1uF.
Pin 7 of the W25Q256 goes to pin 10 of the Teensy. I have added a 10K pullup resistor.
Pin 8 of the W25Q256 goes to pin 12 of the Teensy. 
Pin 10 of the W25Q256 goes to GND.
Pin 15 of the W25Q256 goes to pin 11 of the Teensy. 
Pin 16 of the W25Q256 goes to pin 13 of the Teensy.


Here is the design I have done:

both.PNG

front.PNG

back.PNG

render.PNG

It is my first design, so I would appreciate any insights or recommendations. Am I missing anything important there?

Thank you.
 
The W25Q256 is 16MB flash. It supports QSPI. For T_4.1 usage it would make sense to use the QSPI capable pads on the bottom side for much better processor supported Quad SPI performance. It would likely take minimal update to the W25Q128 8 MB Flash already supported that solders directly to that. That would require a second tiny PCB or manual wiring of some sort to bring those signals to the W25Q256 PCB.

That would keep those pins free and offer much better and faster access.
 
Thank you for your response, defragster.

I think I should have added in my previous post that my intention is to use the flash chip for playing audio files. And AFAIK the Audio library does not support playback from a flash chip through QSPI.
 
Seems it should - QSPI reads from FLASH as 'just a pointer'? Can't confirm - but seems that is the case - others may knwo for sure to say not or point to example ???
 
Hi, all.

I have finally been able to get my breakout board and test it.

20201202_202240.jpg

Unfortunately it failed the RawHardwareTest of the SerialFlash lib. I ran it several times, always after the EraseEverything sketch, with similar results:


Code:
Raw SerialFlash Hardware Test



Read Chip Identification:

  JEDEC ID:     EF 40 19

  Part Nummber: W25Q256FV

  Memory Size:  33554432 bytes

  Block Size:   65536 bytes



Reading Chip...

  Previous data found at address 3026944

  You must fully erase the chip before this test

  found this: FF FF FF FF 7F FF FF FF 

     correct: 00 2E 30 00 CB E9 A6 57 



Tests Failed  :{



The flash chip may be left in an improper state.

You might need to power cycle to return to normal.

Any idea of what the problem could be? a damaged/fake chip?

Thanks in advance.
 
The sketch identifies the part:
Code:
Part Nummber: W25Q256FV
but I think you need W25Q256JV for it to work.

Pete
 
The supported Winbond Flash chips used here are the 8 pin variants

They are 8MB and 16MB - and just received 64MB are being supported ( 8 pin WSON format ) - at least in the LittleFS work in progress - but I have not soldered one up yet.

With those 8 pin chips - soldering to the T_4.1 bottom pads as noted would allow the faster QSPI access at higher clock speeds.

Applicability to "playing audio files" would be an open question ...
 
Any idea of what the problem could be? a damaged/fake chip?

My best guess is SerialFlash is using a 32 bit address with the traditional commands, but this chip defaults to legacy 24 bit addresses on those commands, unless this config bit is written:

sc.jpg
 
These larger Winbond chips (which I did not have available last time I worked on SerialFlash) have a special 32 bit versions of their commands, which work regardless of that config bit setting.

With that in mind, here's a very quick and dirty hack to try.

Find this:

Code:
                if (f & FLAG_32BIT_ADDR) {
                        SPIPORT.transfer([B]0x03[/B]);
                        SPIPORT.transfer16(addr >> 16);
                        SPIPORT.transfer16(addr);
                } else {
                        SPIPORT.transfer16(0x0300 | ((addr >> 16) & 255));
                        SPIPORT.transfer16(addr);
                }

and change 0x03 to 0x13.

Then find this:

Code:
                if (flags & FLAG_32BIT_ADDR) {
                        SPIPORT.transfer([B]0x02[/B]); // program page command
                        SPIPORT.transfer16(addr >> 16);
                        SPIPORT.transfer16(addr);
                } else {
                        SPIPORT.transfer16(0x0200 | ((addr >> 16) & 255));
                        SPIPORT.transfer16(addr);
                }

and change 0x02 to 0x12.

Finally, find this:

Code:
        if (f & FLAG_32BIT_ADDR) {
                SPIPORT.transfer([B]0xD8[/B]);
                SPIPORT.transfer16(addr >> 16);
                SPIPORT.transfer16(addr);
        } else {
                SPIPORT.transfer16(0xD800 | ((addr >> 16) & 255));
                SPIPORT.transfer16(addr);
        }

and change 0xD8 to 0xDC.

Do those edits make it work?
 
Do those edits make it work?

Thank you for the insights Paul. Unfortunately, I have just tried it and did not work.

Code:
Raw SerialFlash Hardware Test


Read Chip Identification:

  JEDEC ID:     EF 40 19

  Part Nummber: W25Q256FV

  Memory Size:  33554432 bytes

  Block Size:   65536 bytes


Reading Chip...


  Previous data found at address 323584

  You must fully erase the chip before this test

  found this: 7F FF FF FF FF FF FF FF 

     correct: 00 04 F0 00 59 81 D3 EF 



Tests Failed  :{



The flash chip may be left in an improper state.

You might need to power cycle to return to normal.


I will try to look deeper into it this weekend, any suggestion about what to look at?



With those 8 pin chips - soldering to the T_4.1 bottom pads as noted would allow the faster QSPI access at higher clock speeds.

Applicability to "playing audio files" would be an open question ...

Yes, in fact I already have a 32MB 8 pin WSON soldered on the bottom, but I am not able to use it to play audio.
BTW @PaulStoffregen, would it be too complicated for a not-really-advanced user to adapt the Audio lib/SerialFlash lib to adapt it for playing audio with the bottom flash chip of the T4.1? I guess if nobody has done it yet it probably will not be that easy.
 
any suggestion about what to look at?

My only other suggestion, which doesn't come with any specific code, would be to craft the SPI message to program that ADP bit.


would it be too complicated for a not-really-advanced user to adapt the Audio lib/SerialFlash lib to adapt it for playing audio with the bottom flash chip of the T4.1? I guess if nobody has done it yet it probably will not be that easy.

Indeed it's not easy. But much of the reason behind the File & FS work that's going into 1.54-beta is to make this possible. I'm planning to look at it "soon". When that comes about, you'll need to use a 1.54-beta if you want to give it a try.
 
It's been some time since this discussion was active, but in the intervening time, I wonder if anyone has made any progress toward audio support via SerialFlash (or some equivalent) using larger Flash NAND chips. I have a Teensy 4.1 with a 256Mb Winbond W25N02KVZEIR QSPI Flash chip. It can be accessed using LittleFS, but apparently not by SerialFlash, which is able to play MP3 files (SerialFlash example MP3Player.ino) from a flash chip on the audio shield. But it would be immensely powerful to be able to play audio (esp. WAV) from the 256Mb chip which is capable of storing up to around 48 minutes of 44.1k audio. Smaller QSPI chips would also offer proportionally lengthy play times.
 
SerialFlash only works with NOR flash chips.
Thanks for the response. I was aware that SerialFlash only works with NOR, but I seemed to recall (perhaps incorrectly) that there had been some discussion about extending support to NAND.

However, what I'm most interested in is having access to a larger flash device (512Mb or 1Gb) for playback of audio files using AudioPlaySerialflashRaw. In the Audio Design Tool, the accompanying image for that player shows a Winbond W25Q128FV, which has a 8-Pin VSOP package, mounted on a Teensy Audio Shield. But the device's 16MB that would provide only about 3 minutes of storage (at most) for mono WAV files. And I need access to a library of 100s of audio samples, with an average length of 5 seconds or more.

However, on the GitHub page for SerialFlash, compatibility is indicated with a number of larger NOR devices (Winbond W25Q256FV, Micron N25Q512A, Micron N25Q00AA, Spansion S25FL127S, Spansion S25FL256S, Spansion S25FL512S) none of which seem to have compatible 8-pin VSOP packages. So I'm wondering how compatibility with these devices was verified.

A final question: would SerialFlash recognize the Winbond W25Q128FV if it were mounted on the Teensy 4.1 rather than the Audio Shield? It's a bit of an academic point, since its limited storage obviates its usefulness for my purposes. This implies a question of whether SerialFlash can take advantage of QSPI when available.
 
No plans to ever support NAND flash in SerialFlash library. The format is uses it tightly tied to the way NOR flash works, so SerialFlash is never anticipated with NAND flash.

And also no on QSPI, but in the future maybe. Unlike NAND, there's no technical limitation preventing QSPI, only limited programming hours and a huge backlog of other much more important things.

Because LittleFS does support QSPI and also NAND flash, updating the older (and lacking power-loss-safe writing but more optimized for reading) SerialFlash library is seen as a particularly low priority.
 
No plans to ever support NAND flash in SerialFlash library. The format is uses it tightly tied to the way NOR flash works, so SerialFlash is never anticipated with NAND flash.

And also no on QSPI, but in the future maybe. Unlike NAND, there's no technical limitation preventing QSPI, only limited programming hours and a huge backlog of other much more important things.

Because LittleFS does support QSPI and also NAND flash, updating the older (and lacking power-loss-safe writing but more optimized for reading) SerialFlash library is seen as a particularly low priority.
Yes, that all makes sense, and is basically what I imagined.

One final follow up, though. Can you describe the conditions in which you were able to test SerialFlash with some of the large non-VSOP package devices? If one needs to build a PCB to host the large NOR devices, I'm open to that.

And, finally, regarding QSPI, my tests with AudioPlaySdWav do reveal a good deal of difference in CPU usage and response when using the Teensy 4.1 built in SD reader vs the one on the Teensy Audio Shield, with the built-in having at least a 2 to 1 performance advantage. I would assume that this is due to QSPI being utilized transparently to AudioPlaySdWav. Is this a correct assumption?
 
Back
Top