Go Down

Topic: SPIFlash library - Now works with Winbond/Microchip/Spansion/Cypress (Read 43246 times) previous topic - next topic


Hi I am trying to use this library to access W25Q64JV with Arduino MEGA. But i coldn't be successful.
W25Q64BV is obsolete and i used W25Q64JV.
Do you have any relevant ideas about this?



W25Q64BV is obsolete? Hmmm... why do you think so?

I have a funny problem with this kind of memory. Namely, I can't find any sketch which demonstrates the simpliest read/write operations with W25 chips. Can someone help with this? 


@ Compucat : I'm afraid I can't explain why that's happening with you. The library appears to work fine with the S25FL127S I have. I'll try out a few other chips this weekend and let you know if I face any issues.

@ TrekRider: I'm afraid the library does not officially support the BluePill. I have had a lot of trouble getting the USB bootloader working on my boards and gave up just before Christmas. However, I'm still keen on supporting the board, so, could you do me a favour and raise an issue on the Github page [here]? I'll get going started again on getting the Blue pill supported. :D

@ kucukkose: Thanks for raising an issue on Github about this. Could you please refer to my comments there and provide a little more information on what exactly the problem seems to be?

@ Gosh: What do you mean by simple sketch to demonstrate read/write operations? Are you looking for code that works with the SPIFlash library or SPI level code?


Mar 09, 2018, 06:36 am Last Edit: Mar 09, 2018, 06:47 am by Marzogh
Update: Library will be renamed in a couple of months.

The term 'SPI Flash' is a fairly common way to refer to Flash memory chips that communicate over the SPI protocol and there are a number of libraries that are named SPIFlash. When I first started work on this library in 2014, it was mostly as an exercise to improve my embedded systems programming skills. When I asked for it to be included in the list of Arduino libraries [in 2015], I did not really expect it to go very far or get very popular. But, before I knew it, I was releasing new versions every other month and I found the number of users got way bigger than I imagined it would. The amount of traffic the GitHub repository gets still surprises me.

A few months ago, Felix Rusu of LowPowerLab raised an issue [#83] about the problems the name of this library was causing the users of his library - also called SPIFlash. The fact that this library is in the Arduino Library manager meant that his users were being asked to upgrade their version of SPIFlash when the libraries were actually different. I can understand how much of an annoyance this can be for a user.

Felix's version of SPIFlash has been around for longer than this one and his library is a major part of his commercial line of development boards. Since I am a hobbyist developer (I'm a full-time geneticist & a part-time dabbler in ecology - if you're curious) and this library is not a commercial product with branding and trademarks to worry about, the least I can do is change the name of this library so it stops being an annoyance to Felix's customers.

On a side note, if you did not know already, Felix makes and sells a fantastic line of Arduino compatible boards - the Moteino series - and has developed a fantastic IoT protocol to use with them to add smarts to your home. In January this year, I finally got around to getting my hands on some of his boards and have been playing around with them. They are fantastic! I'd strongly recommend you check them out - if you haven't already done so.
I asked the Arduino developers if there was a way to migrate this library to a new name without breaking the upgrade path [Issue #6904] and was told that it was not possible. The only way is to pull my version of SPIFlash from the library manager and ask for a renamed version to be included in the library manager after.

So, this is what I have decided to do.:
  • The upcoming version - v3.1.0 - will be the last version to be released under the SPIFlash name.
  • Anyone downloading v3.1.0 of the library will be able to read this notice in the ReadMe file.
  • Anyone using v3.1.0 of the library will also see a notice in their Serial output directing them to the notice in the ReadMe file. (this can be removed by commenting out the "#define PRINTNAMECHANGEALERT" in "SPIFlash.h")
  • Version 3.2.0 will be released in a couple of months (in May most likely) under a new name. I'm currently thinking of calling it SPIMemory - suggestions are welcome.
  • SPIFlash will be removed from the library manager then and replaced with the new one

The only change will have to be made in end-user code will be to change the "#include SPIFlash.h" to "#include SPIMemory.h" (or whatever the new name will be). After the name change, rest assured that older versions will remain accessible and the development history of the library will be preserved.

I apologise for any trouble this might cause you - the end user - but, given the facts, it is the only thing I can do to be fair to Felix.

Thanks again for using SPIFlash and I hope you will continue to find it useful in whatever new name it will take on.


I'm scratching my head on how to use SPIFlash and some sort of Serial function at the same time. I'd like to dump the contents of my flash chip via Serial (FTDI).

I've tried with both SoftwareSerial (on a different pin) and Serial on an ATTINY841. Behaviour is as follows

- Loop with a .println("Hello"); outputs serial data.
- As soon as I add flash.begin(); in setup(), no serial data is ever sent.

I've spent a few hours trying to search for various things, including using SPI and Serial at the same time... which led me to trying SoftwareSerial, but that has no effect. I'm trying various things now... trying to end the serial before using SPIFlash, then using powerDown() after... but that seems to have no effect.



Here's working/broken code.

Code: [Select]
#include <SPIFlash.h>

SPIFlash flash;

void setup()

void loop()
  // Commented out - works. Uncommented - broken.


Update - I think is related to RAM consumption. This code works on a 328P. The TINYT841 only has 512b of RAM. Using SPIFlash puts it way over that.

Not sure if there are any ways to trim memory consumption?


Hi mate, If you go back to the very first few versions of the library the memory consumption should be low enough to work. Give it a go and let me know. :) The old versions also had Attiny support (for the Attiny85) so that should help.

Go Up