Using W25Q256 on Audio shield

[Sandro]

Hi all, I'm experimenting a W25Q256FV 16-pin SOIC 300-mil on Audio shield Rev B (on teensy 3.6, clock 240MHz), in order to store audio files to be played. Actually I have connected the flash chip with short wires:



In write operation I never experimented issues, while reading I've (really NOT frequent) problems (reading errors maybe?): anyone can help me to go a bit deeper and maybe understand what is wrong? Maybe I could try adding a decupling capacitor between Vcc and GND pins close to the chip...

I have also designed an adaptor:



but... before making it I'd like to hear some opinion/tip.
Thanks a lot for any idea!

[MichaelMeissner]

I've tried before and I didn't get anywhere. I tried the Teensy 3.6 and it did not work. I also tried the Teensy 4.0 using the beta audio adapter that allows a T4 to use revision A/B/C audio shields with no luck. Here is the thread:

• https://forum.pjrc.com/threads/57938...emory-(SOIC-8)

Now, when I put the version B of the audio shield on the Teensy 3.6, I could install the 3.6 Teensy Transfer for the Audio Shield, and it could access the files (T4 right now can't use Teensy Transfer because it doesn't have the RAW HID USB support):

• https://forum.pjrc.com/threads/33859...nsfer?p=101306

But as I said in the thread, using SerialFlash did not work (I have used SerialFlash when I had it hooked up outside of the audio shield).

I haven't gotten too far into trying various things. I do have some ideas. Some come from the Better SPI bus design paper:

• https://www.pjrc.com/better-spi-bus-design-in-3-steps/

Here are some of the things I've thought about:

• I wonder whether changing the SCLK and MOSI pins on the 3.x shields affects SerialFlash. I've tried different orderings of setting the MOSI/SCLK and initializing the SPI bus to no avail. At some point, I plan to solder a memory chip to a revision D audio shield to see if that works;
• I want to add pull-up resistors to both pins 6 (flash memory) and 10 (sd card) to see if that helps. Possibly also hard-wiring pin 10 to 3.3v;
• I just got in some chips for tri-stating, but I don't have a breakout setup like you do (yet). However, if it does need to have a tri-state setup, that kind of ruins using it on the audio board;
• With other SPI devices, I have had to play with the SPI clock speed and processor bus speed. However, as I've said, I think I've been able to use the chip outside of the audio shield, so it seems something the audio shield may be doing. However, as I re-read the thread, I see I had problems when the 3.2 speed was faster than 96Mhz, so you might try setting the 3.6 speed down to 24Mhz to see if it works.

I bought this SOIC-8 to DIP adapter made by Sparkfun. I bought the adapter and the flash memory at , and sold by digi-key:

• https://www.sparkfun.com/products/13655
• https://www.digikey.com/product-deta...123-ND/5528943
• https://www.digikey.com/product-deta...SIQ-ND/5803943

The chips I just got from digi-key to do the tri-state tests are:

• https://www.digikey.com/product-deta...44-1-ND/373802
• https://www.digikey.com/product-deta...123-ND/5528943

[Sandro]

Hi Michael, thank you for your answer; I didn't get if you are talking about W25Q256 32M 16-pin chip or about the W25Q128 16M 8-pin chip (which is not my case); I'm using SerialFlash in my code.
Maybe I'm too optimistic, but I belive that there is only some simple electric issues (signal reflections... interferences) because the chip works better by shortening the wires: in a first assembly I had connected the chip using 20mm wires and the result was quite bad; now, with 8-10mm wires the behave is much better.
Since my first post I've added a 100nF capacitor between Vcc and GND and now, after reading the page "Better SPI bus design paper" you suggested, also removed the SD card from the socket on audio board to avoid any possible interference on SPI bus... Let's see, tomorow I'll continue. I'll also test a lower clock speed, even if my application requires 240MHz to offer full performance.

[MichaelMeissner]

Hi Michael, thank you for your answer; I didn't get if you are talking about W25Q256 32M 16-pin chip or about the W25Q128 16M 8-pin chip (which is not my case);

I have the W25Q128JVSIQ (128 megabits, 16 megabytes), but I suspect there may be similar issues with other flash memory chips. But if you are soldering the chip on the audio board, you have to use an 8-pin chip.

Note, I am a software guy, not a hardware guy. So it might be something else completely. I am just guessing at the causes.

If you aren't soldering the board directly onto the audio shield, it may make sense to put it on its own board. That would eliminate issues caused by the audio shield.

I do wonder whether the 3.6 built-in micro SD card would be competitive with the flash memory. On the 3.6, it uses its own SPI bus, so you don't have interference with other devices on the SPI bus. It uses quad SPI instead of the 1 bit SPI used by either the audio shield SD card or flash memory connection. In my case, the primary Teensy I'm using is the Teensy 4.0, and it is harder to access the pins for the micro SD card reader underneath the Teensy. And with a micro SD card, you can go to 32GB or so in terms of memory. When the audio shield was designed, we only had 1 bit SPI external micro SD card readers.

Looking at the schematic for the audio adapter (which I hadn't before now), I see there is a 10k pull-up resistor between 3.3v and each of the 6 and 10 pins, so in theory, you should not need an additional pull-up resistor. Pins 7 (hold in single SPI or IO3 in quad SPI) and 3 (WP in single SPI or IO2 in quad SPI) of the memory chip are wired to 3.3v, so you are pretty much limited to single SPI.

Similarly, for the micro SD card, 2 of the pins (DAT1, DAT2) are not connected.

And yeah, I probably forgot to take out the SD card when I was doing the initial tests.

[Sandro]

I do wonder whether the 3.6 built-in micro SD card would be competitive with the flash memory. On the 3.6, it uses its own SPI bus, so you don't have interference with other devices on the SPI bus. It uses quad SPI instead of the 1 bit SPI used by either the audio shield SD card or flash memory connection. In my case, the primary Teensy I'm using is the Teensy 4.0, and it is harder to access the pins for the micro SD card reader underneath the Teensy.

This is so important to me! I didn't know this fact of quad SPI... Maybe it means that reading data rate from micro SD card on Teensy is comparable/faster than from flash memory soldered on Audio shield.. I'll try very soon to switch my code from flash memory chip to Teensy/local micro SD card, and compare both.

And with a micro SD card, you can go to 32GB or so in terms of memory.

Yes this is a great plus of micro SD... much more memory than I need by the way but... it's not a disadvantage!

[MichaelMeissner]

This is so important to me! I didn't know this fact of quad SPI... Maybe it means that reading data rate from micro SD card on Teensy is comparable/faster than from flash memory soldered on Audio shield.. I'll try very soon to switch my code from flash memory chip to Teensy/local micro SD card, and compare both.


Yes this is a great plus of micro SD... much more memory than I need by the way but... it's not a disadvantage!

Be sure to use a fast SD-HC card for your tests. Also format the card just before doing the test so the filesystem is not fragmented.

I'm not sure whether the software or hardware support SD-XC cards (i.e. >= 64GB) and the exFat file system used for 64GB and greater..

Another advantage of micro SD cards is you can take them off of the Teensy and read them directly on your computer.

But if you were still wanting to do flash, FrankB posted a 'parallel SPI flash' library. I have not used it (and in fact had forgotten about it until this thread started and I noticed a reference to it). You won't be able to use the audio card, since that does not hook up the extra pins:

• https://forum.pjrc.com/threads/34131-Parallel-SPI-Flash
• https://github.com/FrankBoesing/ParallelFlash.git

[Sandro]

Be sure to use a fast SD-HC card for your tests. Also format the card just before doing the test so the filesystem is not fragmented.

Good suggestion! I had not considered this!

I'm not sure whether the software or hardware support SD-XC cards (i.e. >= 64GB) and the exFat file system used for 64GB and greater..

For my application, the midi expander:
https://forum.pjrc.com/threads/57897-queued-Lilla

100M for file system is more than enough!!

But if you were still wanting to do flash, FrankB posted a 'parallel SPI flash' library. I have not used it (and in fact had forgotten about it until this thread started and I noticed a reference to it). You won't be able to use the audio card

Could also be interesting if I coud "replace" the Audio shield codec with an SPDIF output but, as long as I have experimented, SPDIF cannot replce the Audio shield: I experiment bad audio "clicks" with SPDIF, with the intense audio activity of my application; also should be checked if 'parallel SPI flash' library is compatible with SPDIF. Besides, I need stereo and 16bit accuracy (no way for PCM output, I belive).

Let's see: in my library I'm replacing all flash reading procedures with SD procedures ... next, after the necessary debugging, I'll be ready to do some tests

Thank you Michael!

[Sandro]

But... I found this post:

https://forum.pjrc.com/threads/55662...ight=playSDraw

It says that for polyphonic application (mine uses 8 voices at least) it's raccomanded flash chip, not SD card... maybe I should abandon the idea of switching my project to SD ... an go on with making an adaptor for W25Q256FV.

[MichaelMeissner]

Note, the original post is about the Teensy 3.2 and the audio shield SD card.

I suspect that with either the built-in SD card or flash memory using SPI quad that it would be much faster. Ultimately, both are just flash memory ports that can transfer up to 4 bits at a time. A micro SD card is just a flash memory chip with the pins brought out.

It ultimately will likely depend on several things:

• The exact speed of the micro SD card or the flash memory;
• Whether you have to slow down the SPI bus for the card/flash memory;
• Whether you have to slow down the processor speed because the Teensy is running too fast;
• Whether or not the driver works with interrupts enabled, or it disables interrupts while dealing with the flash;
• If there are other things on the SPI bus;
• Caching behavior of the Teensy 4.0 (which in turn depends on which memory bank you are using and whether you have to flush the cache); (or)
• If you have hardware SPI optimization enabled (this is different between the Teensy 3.6 and 4.0).

Of course the only way to know for certain is to try it.

[Sandro]

Note, the original post is about the Teensy 3.2 and the audio shield SD card.

Hi Michael,
I had not notice that!

So.. thank you for your detailed analysis: at the moment I would remain on Teensy 3.6, or maybe switch to T4.0 in a next release; and for all the topics you point out I have no answers... I can only try to modify my code and see what happend using the SD card on my Teensy 3.6.... Even if it seems that I've reached a good point with the 32MB chip: with this cabling

Attachment 18351

(really not so nice to see!!) my device is working good: not any clicks or other problems after 1 hr of sound tests. This seems to confirm that in the previous arrangement there were electric problems.


About switching my code from flash memory to SD, I unfortunately don't understand how play_SD_raw works... So this change will take long time. Don't even know what help to ask, because my library is too long and I don't want to annoy anyone. In a nutshell, I started with some trivial Ctrl-C / Ctrl-V from play_SD_raw, replacing this code:

    rawfile = SerialFlash.open(filename);
    AudioStartUsingSPI();
    if(!rawfile)
        AudioStopUsingSPI();

with this:

#if defined(HAS_KINETIS_SDHC)
    if (!(SIM_SCGC3 & SIM_SCGC3_SDHC))
        AudioStartUsingSPI();
    #else
        Serial.println("failed!");
        AudioStartUsingSPI();
    #endif

    __disable_irq();
    rawfile = SD.open(filename);
    __enable_irq();
    if (!rawfile)
    {
        //Serial.println("unable to open file");
        #if defined(HAS_KINETIS_SDHC)
            if (!(SIM_SCGC3 & SIM_SCGC3_SDHC))
                AudioStopUsingSPI();
        #else
            AudioStopUsingSPI();
        #endif
        return false;
    }

Is it a good start-point?

[Sandro]

Sorry, here:

#else
        Serial.println("failed!");
        AudioStartUsingSPI();
 #endif

Serial.println("failed!") is a refuse.

Ok, in order to understand something about playSDraw, first I'll look for the meaning of these values:
HAS_KINETIS_SDHC
SIM_SCGC3
SIM_SCGC3_SDHC

[Sandro]

Attachment 18351

The attached pic was this:


In these day I went on with my tests... and this assembly showed some limit: with intense use of the chip some errors appares. I guess if a small PCB with its groun plane could help data transmission. In the meanwhile I'm trying to switch my code to playSDraw.