W25Q256 breakout for Teensy 4.1

[JotaEfe13]

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:



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




The mapping would be the following:

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:









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

Thank you.

[defragster]

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.

[JotaEfe13]

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.

[defragster]

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 ???

[JotaEfe13]

Hi, all.

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



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

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.

[el_supremo]

The sketch identifies the part:

Part Nummber: W25Q256FV

but I think you need W25Q256JV for it to work.

Pete

[JotaEfe13]

True. I didn't realized it has an F instead a J, that is what the chip is supposed to be.

[defragster]

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 ...

[PaulStoffregen]

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:

[PaulStoffregen]

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:

                if (f & FLAG_32BIT_ADDR) {
                        SPIPORT.transfer(0x03);
                        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:

                if (flags & FLAG_32BIT_ADDR) {
                        SPIPORT.transfer(0x02); // 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:

        if (f & FLAG_32BIT_ADDR) {
                SPIPORT.transfer(0xD8);
                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?

[JotaEfe13]

Do those edits make it work?

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

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.

[PaulStoffregen]

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.