Will Paul's SPIFlash library work with these?

Status
Not open for further replies.

linuxgeek

Well-known member
Bought a 128MBit and 1Gbit version of onehorse's SPI Flash modules. Look really awesome BTW.:
https://www.tindie.com/products/onehorse/spi-flash-memory-add-ons-for-teensy-3x/

It uses these Spansion chips:

http://www.mouser.com/ds/2/380/S25FL127S_00-247997.pdf
http://www.mouser.com/ds/2/380/S70FL01GS-275030.pdf

I didn't really know that Paul had an SPIFlash library before picking those up. Will Paul's SPIFlash library work with those chips I mentioned?
https://github.com/PaulStoffregen/SPIFlash

Would like to use Paul's SPIFlash library with SPI transactions, especially since I will try to convert the ADS129x library that someone posted to SPI transactions.

Thanks in advance.
 
Hi there,

Did you ever figure out if the S70FL01GS works with SerialFlash? I have the 512 Mb version now (64MB) and want to upgrade to get more space... the 1G version is the only chip I can find in the proper form factor.

It looks like Paul is in the process of testing the chips (given the file https://github.com/PaulStoffregen/SerialFlash/blob/master/tests.txt), but there is no info on whether the chips have passed or not. I'm sure it will work eventually, but I would like to have it working prior to purchasing it.

Thanks
 
It looks like Paul is in the process of testing the chips

Actually, I'm still in the process of building up hardware to test all those chips.

serialflashtest.jpg
(click for full size)

As you can see in this photo, one of the OSH Park boards only recently arrived and hasn't even been soldered yet. But eventually these boards will let me test all those chips, with much less effort than I did fiddling with the first 7 parts.

Update: here's the test board.

sflashtest.jpg
 
Last edited:
Thanks for the update, Paul.

A more thorough reading of the datasheet indicates that S70FL01GS (1Gb SIOC) will *not* work with the Serial Flash library (or more specifically, that it is implemented as two distinct 512Mb dies with separate CS pins, so that you can only access one 512Mb chip at a time). So that chip is out for me (my hardware is set up for one CS pin, and even if I wanted to dead bug it I don't have any more pins available).

Micron's N25Q00AA13GSF40G appears to be pin compatible with the other SIOC-16 chips (notably Spansion's 512Mb one that I am using now), and appears to only have one CS pin, so I think that one will work from a hardware POV. No clue if it will work with the software yet, though. I guess I will have to either bite the bullet and try it myself, or wait until your testing has progressed.

If I decide to go ahead and try that myself, I will let you know my results. Likewise, if there is any way that I can help, let me know.

Cheers
 
Oh, yeah, that's a good point on the Spansion chip. Only half the chip will be usable.

That Micron part is very likely to work. I previous tested a N25Q00AA. I'm not sure if the suffix on the part number was identical.

Truth is, I was a bit sloppy about documenting which chips I tested while initially developing the library. That's why I'm building a new set of test hardware will all the part numbers carefully documented.
 
Cool, thanks for the confirmation. Even a 'likely to work' is good enough for me (for $20 inc. shipping I can afford to completely FUBAR it)... I'll probably order the Micron chip this week and let you know my results.

Cheers
 
FYI, my new flash chip arrived today, and I can confirm that the Micron N25Q00AA13GSF40G chip (Digikey part #557-1571-5-ND) works fine with the SerialFlash library, and all 128MB are available. Writing (and especially erasing) is *much* slower than the Spansion 64MB chip, but if you are patient it completes eventually. (For comparison, the 64MB Spansion chip S25FL512SAGMFI011 takes about 90 seconds for a full erase; my new one takes almost 10 minutes. I thought it had hung and started to root through the code to see what was happening, when finally it completed). Writing is also a bit slower; when uploading over the USB serial port, the old chip could get about 250KB/s throughput (this depends on the Teensy, the computer, the USB connection, etc, so is not a good benchmark for write performance); however, the new one averages around 190KB/s.

All that said, the read performance appears to be identical, which is what I care about - I don't plan on formatting the chip very often - so I am now a happy camper with twice the space that I had before! :)

Not that it really matters to most people, but you should note that the pinout is slightly different than the Spansion. In particular, the Spansion has internal pullups on W# and HOLD#, whereas the Micron does not. You need to pull these pins high for it to work. Also, the Spansion had a second voltage supply (VIO) on pin 14, whereas the Micron's pin 14 is DNU (Do Not Use). On my board, I just used some jumpers to connect VCC and W# / Hold#, and bent pin 14 up so that it was not connected. Yeah, it's a hack, but it works.

Cheers
 
Have you done erase/write/read/compare on some random blocks/pages?
(This is not in the context of SPI, but rather, SDIO 1 bit or 4 or 8 bit, or MMC/eMMC). FSMC/Parallel 8 bit is the industry norm for NAND flash chips and the M4 and higher ARMs when used with Gbit NAND flash. FMSC is also used with static RAM, different chip select.

I'm testing MLC now. Have done a Samsung 4Gbit SLC NAND chip in TSOP form and being SLC, the bit error rates is low enough to use 1 bit ECC. The host MCU's FSMC/8 bit parallel interface does that simple hamming code ECC. Such as the STM32F4xx; Freescale likely has the same. MCUs don't have the 4 bit ECC capability needed for MLC at 8 or 16Gb.

I'm working with Micron 16Gb MLC NAND flash. At 4Gbit and lower, it's SLC flash; greater, it's MLC. And MLC takes 4+ bits of ECC for error correction since they say, with MLC the bit error rate is so high that ECC is needed. And ECC is too slow to do in the host. So Toshiba, Micron, others make ECC-on-die now, for MLC. The other flash translation layer (FTL) functions, bad block management, logical to physical block address translation, and wear-leveling, is done in the host MCU (large, complex code, fair amount of RAM).
But most of their raw NAND flash do not use ECC on die - because smart phones and the like have a flash controller chip to do ECC and the FTL functions as above. Phison seems prominent in the controller space.

You can buy TSOP and other packaged (non-die form) parts that have the controller and NAND flash array die(s) inbuilt. Usually with an SDIO or eMMC interface, not parallel FSMC. Such are available from Spansion, Toshiba and Micron, among others. With the controller, all the horrors of MLC error rates are taken care of by the controller and the host MCU is blissfully unaware.

NOR flash, much smaller/slower, doesn't suffer the error rate problems.
 
Last edited:
I have not; I just formatted (erased) the card, and copied some raw audio files onto it using the SerialFlash library. I then played the audio back using the play from serial flash Audio library objects, and made sure that the audio sounded good.

That said, the datasheet for both the Spansion and Micron chips that I have tried say that they are NOR Flash Memory, so I am going to assume that your experience with NAND is irrelevant here. (I am not an expert on flash memory implementation details, so feel free to correct me).

Cheers
 
... so I am going to assume that your experience with NAND is irrelevant here.

Yeah, Steve does this all the time... lots of good but off-topic info, usually technically correct, sometimes related, sometimes a very unrelated thing he's working on using a totally different processor, all mixed together into one confusing jumble.

The SerialFlash library doesn't support *any* NAND flash chips.
 
Yeah, Steve does this all the time... lots of good but off-topic info, usually technically correct, sometimes related, sometimes a very unrelated thing he's working on using a totally different processor, all mixed together into one confusing jumble.

The SerialFlash library doesn't support *any* NAND flash chips.
Sorry. Until you guys replied to my missive, I did not know you were using NOR flash. Most all large storage in use is NAND flash and NOR is most often used in read-mostly applications such as test equipment.

Note too the terminology confusion: "serial flash" in the NAND MLC world means the bit movements within the array, not the host interface.

I hadn't found that the SerialFlash library (e.g., for the smaller MBit chips), was not for NAND.

I was sincerely trying to help you guys (assuming NAND flash), due to the ECC issues with it - which aren't well understood in the industry. So to my pea brain, it wasn't at the time irrelevant.
 
Last edited:
Sorry to report that I have not done anyhing with the SPI memory chips yet.

I've had to investigate a couple of sensors for 2 other projects and have had to pause work on the project that was going to use these chips.
Great info here though. Thanks.
 
Hello,
I'm planning to use external flash(but using them more like external SRAM), too
with winbond W25Q40CL,80BL,or16CL (512KB/1MB/2MB)
and more like EEPROM, storing data in byte arrays.

I haven't start any actual coding yet,
so I shall follow this post ,and glad to see any more details update.
 
Winbond W25Q80BV was reported working. I did not personally test it, but since someone confirmed it works, that chip would be a good starting point. The others might work too.

If you're looking to access the chip as raw bytes, the simple SPIFlash library might be better.

Of course, these are flash memory which is different from RAM. The main issues are slow write speed, very slow erase speed, the need to erase before writing, and limited endurance for repeated writing.
 
yes, Paul, nice to hear they worked
reading over the those flash libraries and I found out they all specific noted,
THE BLOCK NEED TO BE ERASED BEFORE WRITING,
or some other warning like that,

the data sheet gives about 133MHZ for the SPI Flash chips, reading should not be a problem
but I would need to test that erase/writing time cost soon,

I checked some sram chips on WINBOND, they all seemed to work at 1.8V, which would need additional hardware(Vregulators, signal raising/whatever)
I don't think there is a library exist for them and I have no idea to deal with VFBGA. Storage size above 128MB is also overkilling,
okay, spotted some worked with 2.7V~3.6V , but with TSOP 54, still another a nightmare

meanwhile, I recalled there's a FRAM product at adafruit ( https://www.adafruit.com/products/1895)
I should test some of those also.
 
I have used the SerialFlash library to do a file erase (without marking the file as erasable beforehand). This does not reclaim the space, but allows a new file with the same name to be written. If your needs include caching smaller amounts of data this may work for you.

As for chip erase time, it seems to vary greatly based on chip and size. I have personally used three flash chips so far - Winbond W25Q128FVSIG (16MB), Spansion S25FL512SAGMFI011 (64MB), and Micron N25Q00AA13GSF40G (128MB). Of these, the Winbond takes around 20 - 30 seconds to erase, the Spansion takes about 90 seconds, and the Micron takes almost 10 minutes.

Even without talking about full erases, write speeds are much slower than reading. If your use case is mostly reading with an occasional write, these chips may be fine. If you want to use it as RAM with frequent transient writes, reads, and deletes, I think that you should look elsewhere.

Cheers
 
As for chip erase time, it seems to vary greatly based on chip and size. I have personally used three flash chips so far - Winbond W25Q128FVSIG (16MB), Spansion S25FL512SAGMFI011 (64MB), and Micron N25Q00AA13GSF40G (128MB). Of these, the Winbond takes around 20 - 30 seconds to erase, the Spansion takes about 90 seconds, and the Micron takes almost 10 minutes.

glad I'm heading for testing winbond and not micron, waiting for their samples
Erasing a picture, which carries 32KB at max, would take approx 50ms, if the time needed to erase is equally distributed, and that's acceptable in my project:p
still need to know how much time needed to write, or writing durability,


and I'm also looking in FRAM samples, http://edevice.fujitsu.com/fj/catalog/en-pdf/AD05-00033-8E.pdf
The FRAM provides much less storage space, though still enough.

they would be used in next POV project, for pixels more than 72, or more. maybe I'm worrying too much now.
I shall test them both, anyway.:rolleyes:
 
Last edited:
Durability is in the data sheets (100000 erase cycles for the chips I looked at, IIRC... but don't take my word for it as this is just from memory). Write speed was not listed from what I could see (at least in the 2 data sheets I looked at in depth), but in real life applications I get about 200 - 250KB/s upload speed over USB serial, so this can give you an absolute worst case scenario write speed (keeping in mind that these numbers include USB serial and processing overhead).

I have no idea if erasing blocks is proportionally as fast as erasing a die; my application is (mostly) erase / write once / read many, so I have not really looked at per-block erase times.
 
(Hmm... I just replied but I think the forum ate it. I'll try to get everything here again)

-Erase durability is in the datasheets. I seem to recall 100000 erase cycles but could be wrong - please verify for your chips.
-Real world write speed on a previously erased chip is 200 - 250KB/s (bytes, not bits). This includes reading from USB serial and processing overhead, so actual write times is likely faster. This does depend on the chip to some extent; the Micron is at the lower end (200KB/s) while the Spansion was at the higher end (250KB/s).
-I have no experience to say whether block erase is proportionally the same speed as die erase; I have not tried that, sorry.

Cheers
 
thanks for your data, using 100k erase cycles to estimate, if each time the product erases approx 100 cycles at max(and ofcourse could be distributed, but let's assume it stays at the same block, or page)
that means the POV could play about 1000 times, in heavy usage performancer ,worst situation is that could be worn out in six months, that's a bad news to know,:(
though average users should be able to use it for 20 months?

verifying? does that means erase could accidentally fail? or commonly need to check, which slows down erase speed?

200-250KB, means 160ms for a 32KB picture, and again, if the time needed to write is equally distributed
same question lies on write a byte, many bytes, or a page.... read is fast so I guess we can ignore the difference reading a byte or page.

The speed is still upper bounded to SD in my project ,but will not be a problem , if I discovered how to use DMA:(

also from the DATA sheet , FRAM has a 10 trillion read/write cycle, nothing to worn out. and SPI with 30MHZ seems enough?
write speed not shown, it says fast anyway.
 
Last edited:
The speed is still upper bounded to SD in my project ,but will not be a problem , if I discovered how to use DMA:(

The SerialFlash library does not currently use DMA (SPI FIFO), although there is a comment in there as a TODO. I don't currently have the experience to do that, but I may eventually look into it. I am using the flash chips to store digital audio, and can currently play back 15 concurrent audio files (each audio file 16 bit / sample, 44100 samples / second, to give you an idea of read throughput). These stats are with the Teensy overclocked to 120MHz; at 96MHz I can get around 11 or 12 concurrent audio files.
 
Hello,

I'm also currently looking for a "fast" and high endurance FRAM SPI chip and I found that one from Fujitsu, MB85RS512T. It's a 512kbit chip, but it also exists in 128kbits, 256kbit, 1 and 2Mbits. Paul, do you think that your library will support this chip ?

Here the link for the general documentation, https://www.fujitsu.com/uk/Images/c29.pdf, page 4 is the one with FRAM SPI.

I only found preliminary version of the datasheet in English, https://www.fujitsu.com/us/Images/MB85RS512T-DS501-00029-0v01-E.pdf

But the datasheet are in final version for the other sizes of the chips.

At this time I found a lib for Arduino which have been developed for those chips (256kbits max), but it doesn't use transactional SPI and that will be annoying in my dev where SPI bus is used for other peripherals (display, motor driver).

I also found that Everspin have a nice MRAM chip, that seems working like FRAM, with no endurance limitations nor write delays, the MR25H10 (1 Mbits).

Here the datasheet : https://www.everspin.com/file/208/download

Have you heard about it ? Same question, could it work with Paul's library ?

Thanks!
 
Last edited:
Hello,

I'm also currently looking for a "fast" and high endurance FRAM SPI chip and I found that one from Fujitsu, MB85RS512T. It's a 512kbit chip, but it also exists in 128kbits, 256kbit, 1 and 2Mbits. Paul, do you think that your library will support this chip ?

Here the link for the general documentation, https://www.fujitsu.com/uk/Images/c29.pdf, page 4 is the one with FRAM SPI.

I only found preliminary version of the datasheet in English, https://www.fujitsu.com/us/Images/MB85RS512T-DS501-00029-0v01-E.pdf

But the datasheet are in final version for the other sizes of the chipset.

At this time I found a lib for Arduino which have been developed for those chips (256kbits max), but it doesn't use transactional SPI and that will be annoying in my dev where SPI bus is used for other peripherals (display, motor driver).

I also found that Everspin have a nice MRAM chip, that seems working like FRAM, with no endurance limitations nor write delays, the MR25H10 (1 Mbits).

Here the datasheet : https://www.everspin.com/file/208/download

Have you heard about it ? Same question, could it work with Paul's library ?

Thanks!

I don't think so as it more like RAM than Flash. In addition even the largest, 2MBit (=256KB) is a bit small to store files...

Edit: I took a quick look at the Datasheets, it seems to be compatible to the RAMs, so it's likely that this library (provides only basic functionality, but what should it do more with only 256Kb...) works.

What is the price for the 2MBit chip ? Perhaps i'd be interested to buy some.. to try them on the memoryboard
.
BTW; there are variants of the well known 23LC1024 (1MBit) with VBAT - Pin.
 
Last edited:
Hi Frank,

Thanks for your quick reply. For the Everspin chip, it does exists in 1, 2 and 4Mbits versions. Have a look here : https://www.everspin.com/serial-peripheral-interface
And if you are looking at this page, there is and Arduino evaluation board that exists, so I would like to think that those chip are compatible with regular SPI Serial Flash library. What do you think ?

Here some interesting informations:
https://www.everspin.com/family/mr25h10
http://www.fujitsu.com/global/produ...emory/fram/lineup/spi-2m-rs2mt/press-new.html

On my side I'm looking in a "fast" buffer, quite large, to store uint16_t var every 10ms for about 1 minute, which would fit in my case in 128kbit, 256kbit looks comfortable and allows me a faster sampling, maybe not in your case... If my math are correct ;)

The cost for M25H10CDC is around $5 (http://www.futureelectronics.com/en...emory/mram/Pages/4150413-MR25H10CDC.aspx?IM=0) per chip, 2 minimum qty)

For M25H40CDC, around $11 (http://www.futureelectronics.com/en...emory/mram/Pages/1006122-MR25H40CDC.aspx?IM=0)

The Fujitsu MB85RS512T for the 512kbit is around $5 also at digikey (http://www.digikey.com/product-deta.../MB85RS512TPNF-G-JNERE1/865-1273-1-ND/5456447)
And the 2Mbit, MB85RS2MT, is around the same price here (http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=48922) which is more affordable than the Everspin one even if limited to 2Mbit.

What do you think ?
 
Last edited:
Status
Not open for further replies.
Back
Top