LittleFS port to Teensy/SPIFlash

Good luck Kurt with the LA.

@defragster
I was reading Paul's post in the beta5 thread and remembered that I put together a benchmark sketch based off of the SDFat benchmark sketch. So decided to run in on the N01 chip:

...

That looks like a good test. I'll find a 'l'etter and add it into LFSintegrity rather than compromise the validation checking done on the others.

Would be fun to do that with dirty and cleanly formatted media.

Should add a 'delete all' too. Though 'q'uick format does that well enough.
 
Good luck Kurt with the LA.
Again you can configure it for normal SPI and not dual/or quad...
And depending on which device family you configure for, it tries to know the different commands to set it into dual or quad and decode from there...
Right now I have both configured as WINBOND with 24 bit addressing.

Here shows with external flash board, LA pins(11, 12, 13, 3, 4, 5, 6) I have two of the SPI Flash analyzers with CS for 5 and 6. I also have an SPI analyzer with pin 5...

Here is startup of MTP-test sketch
screenshot.jpg

zommed in to read ID...
screenshot2.jpg
 
On TD 1.54 b5 thread the _Program flash moved to 133 MHz by paul. Tested and it worked - but no faster versus p#719 test

Quick Summary:
Code:
	Big write KBytes per second 532.36 
Bytes Used: 3133440, Bytes Total:6291456

printDirectory PRO_DISK
--------------
FILE	0_bigfile.txt		3119104

	Big read&compare KBytes per second 2686.95 

[B]// 100 iterations time 2.83 M[/B]
[  2.60 M](0.01360 M elap) Awaiting input 0123456789RdcghkFqvplmusSBbyYxfan+-? loops left 0 >h
:: /B_file.txt  PRO_DISK +++ Add [sz 0 add 5120] @KB/sec 417.01 {412.34}  ++ B   Verify /B_file.txt 5120B  @KB/sec 2605.60 
:: /C_file.txt  PRO_DISK +++ Add [sz 0 add 9216] @KB/sec 453.59 {450.24}  ++ C   Verify /C_file.txt 9216B  @KB/sec 2719.39 
:: /D_file.txt  PRO_DISK +++ Add [sz 0 add 13312] @KB/sec 451.09 {448.47}  ++ D   Verify /D_file.txt 13312B  @KB/sec 2736.84 
:: /E_file.txt  PRO_DISK +++ Add [sz 0 add 17408] @KB/sec 446.94 {444.77}  ++ E   Verify /E_file.txt 17408B  @KB/sec 2693.90 ...

...

:: /Z_file.txt   Verify /Z_file.txt 103424B  @KB/sec 2764.24 
 PRO_DISK ----DEL---- -- Z
:: /A_file.txt   Verify /A_file.txt 41984B  @KB/sec 2757.21 
 PRO_DISK ----DEL---- -- A
:: /B_file.txt  PRO_DISK +++ Add [sz 0 add 5120] @KB/sec 419.91 {411.51}  ++ B   Verify /B_file.txt 5120B  @KB/sec 2656.98 
:: /C_file.txt  PRO_DISK +++ Add [sz 0 add 9216] @KB/sec 458.80 {453.81}  ++ C   Verify /C_file.txt 9216B  @KB/sec 2674.41 
:: /D_file.txt  PRO_DISK +++ Add [sz 0 add 13312] @KB/sec 470.16 {465.02}  ++ D   Verify /D_file.txt 13312B  @KB/sec 2672.02 

[  5.47 M](2.83065 M elap) Awaiting input 0123456789RdcghkFqvplmusSBbyYxfan+-? loops left 0 >

Big write /0_2MBfile.txt took  3.87 Sec for 2048000 Bytes : file3.size()=2048000
	Big write KBytes per second 529.07
 
'g' run speedBench() :: Done and integrated - here tested on _Program {ADDED the 1GB NANDs} :: Running at new PJRC 133 MHz setting in bootdata.c

Going to fix Delata - Ran after UPLOAD so all was Formatted.
Did Disk Fill to dirty blocks - made room and redid the new : 'g' run speedBench()
Clean or dirty doesn't matter here - BOTH data for WRITE test below:
Code:
write speed and latency[B]  // FORMATTED TO START[/B]
speed,max,min,avg
KB/Sec,usec,usec,usec
496.48,4790,3210,4062
528.52,4420,3369,3862
496.48,4420,3369,4112
528.52,4421,3368,3862
512.00,4141,3407,3987

write speed and latency[B]  // DIRTY unFORMATTED TO START[/B]
speed,max,min,avg
KB/Sec,usec,usec,usec
481.88,4631,3215,4172
512.00,4421,3229,3862
496.48,4632,3369,4112
528.52,4421,3369,3862
512.00,4632,3368,3987

Starting sequential read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
115380.28,32,7,17
297890.91,9,6,6
309132.06,7,6,6
309132.06,7,6,6
315076.94,8,6,6

Done

Starting random read test, please wait.
Number of random reads: 1
Number of blocks: 8

read speed and latency
speed,max,min,avg
Position (bytes), Block: 0, 0
Read Time (ARM Cycle Delata): 3946
KB/Sec,usec,usec,usec
33711.93,0,0,60
Position (bytes), Block: 8192, 4
Read Time (ARM Cycle Delata): 4220
KB/Sec,usec,usec,usec
1024000.00,0,0,2
Position (bytes), Block: 10240, 5
Read Time (ARM Cycle Delata): 4706
KB/Sec,usec,usec,usec
963764.69,0,0,2
Position (bytes), Block: 2048, 1
Read Time (ARM Cycle Delata): 3962
KB/Sec,usec,usec,usec
1024000.00,0,0,2
Position (bytes), Block: 6144, 3
Read Time (ARM Cycle Delata): 4933
KB/Sec,usec,usec,usec
963764.69,0,0,2


And for QSPI_NAND: // FORMATTED TO START : and added "szDiskMem" to the BenchMark title::
Code:
QSPI_NAND Benchmark:
FILE_SIZE = 16384
BUF_SIZE = 2048 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
1170.29,755,705,1750
1260.31,755,704,1658
1260.31,755,704,1658
1260.31,755,704,1646
1170.29,755,704,1659

Starting sequential read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
20029.34,103,102,102
20029.34,103,102,102
20029.34,103,102,102
20029.34,103,102,102
20029.34,103,102,102

Done

Starting random read test, please wait.
Number of random reads: 1
Number of blocks: 8

read speed and latency
speed,max,min,avg
Position (bytes), Block: 0, 0
Read Time (ARM Cycle Delta): 61371
KB/Sec,usec,usec,usec
147603.61,0,0,13
Position (bytes), Block: 8192, 4
Read Time (ARM Cycle Delta): 61378
KB/Sec,usec,usec,usec
147603.61,0,0,13
Position (bytes), Block: 10240, 5
Read Time (ARM Cycle Delta): 61384
KB/Sec,usec,usec,usec
147603.61,0,0,13
Position (bytes), Block: 2048, 1
Read Time (ARM Cycle Delta): 61374
KB/Sec,usec,usec,usec
147603.61,0,0,13
Position (bytes), Block: 6144, 3
Read Time (ARM Cycle Delta): 61378
KB/Sec,usec,usec,usec
147603.61,0,0,13


And for SPI_NAND: // FORMATTED TO START : and added "szDiskMem" to the BenchMark title::
Code:
SPI_NAND Benchmark:
FILE_SIZE = 16384
BUF_SIZE = 2048 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
372.36,1388,1340,5405
409.60,1388,1339,5011
409.60,1388,1340,5011
409.60,1389,1339,5012
409.60,1389,1339,5012

Starting sequential read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
4641.36,441,441,441
4640.05,442,440,441
4641.36,441,441,441
4640.05,442,441,441
4641.36,441,441,441

Done

Starting random read test, please wait.
Number of random reads: 1
Number of blocks: 8

read speed and latency
speed,max,min,avg
Position (bytes), Block: 0, 0
Read Time (ARM Cycle Delta): 265419
KB/Sec,usec,usec,usec
36328.16,0,0,56
Position (bytes), Block: 8192, 4
Read Time (ARM Cycle Delta): 265425
KB/Sec,usec,usec,usec
36328.16,0,0,56
Position (bytes), Block: 10240, 5
Read Time (ARM Cycle Delta): 265320
KB/Sec,usec,usec,usec
36328.16,0,0,56
Position (bytes), Block: 2048, 1
Read Time (ARM Cycle Delta): 265331
KB/Sec,usec,usec,usec
36328.16,0,0,56
Position (bytes), Block: 6144, 3
Read Time (ARM Cycle Delta): 265394
KB/Sec,usec,usec,usec
36328.16,0,0,56

Updating github now ...
 
Last edited:
Looks good, hopefully tomorrow I will run some of these tests as well..

Been hacking MTP instead today and I think I have some events stuff working now also with the T3.x boards :D
 
Again you can configure it for normal SPI and not dual/or quad...
And depending on which device family you configure for, it tries to know the different commands to set it into dual or quad and decode from there...
Right now I have both configured as WINBOND with 24 bit addressing.

Here shows with external flash board, LA pins(11, 12, 13, 3, 4, 5, 6) I have two of the SPI Flash analyzers with CS for 5 and 6. I also have an SPI analyzer with pin 5...

Here is startup of MTP-test sketch
View attachment 23027

zommed in to read ID...
View attachment 23028

@KurtE = looking good. EF7020 - Winbond W25Q512JV*IM (DTR) from the list of FLASH chips :) Can't wait to see QSPI.
 
@defragster
Runs look good - just about matches what I saw on the standalone versions. Thanks for adding :)
 
@defragster - @KurtE
Pushed a update to the NAND lib to fix a couple of bugs I have in readECC function (SPI and QSPI). Going to see what happens if I add an error to the BBLUT table and enable BBM. Going to take a chance.
 
@defragster - @KurtE
Pushed a update to the NAND lib to fix a couple of bugs I have in readECC function (SPI and QSPI). Going to see what happens if I add an error to the BBLUT table and enable BBM. Going to take a chance.

Which library? The last one I see up at LFSIntegrity is @defragsters added speedBench
 
@defragster - @KurtE

I think I figured out how ECC bad block management works for at least the W25N01 and probably the W25M02 (think I have to fix something with readBLUT function though - maybe). But makes it alot more difficult with LittleFS to implement. With that said I mentioned this before but now up to the point where probably makes a difference. Have a look at this: https://bioreports.net/armmbed-littlefs/#wear-leveling and let me know what you think - is BBM worth trying to figure out on it working with LittlFS.
 
@defragster
Runs look good - just about matches what I saw on the standalone versions. Thanks for adding :)

Good to have Benchmark in there for reference! I did the ones posted but not any FRAM or PSRAM.

Interesting if the ECC and bad block stuff is functionalfor the NANDs - Paul noted he didn't expect it working in TD 1.54? Seems to work as well as the others - especially if that hole is plugged for bad spots on the media.

Gotta run for now ...
 
Sorry it may be beyond my pay grade ;) But as mentioned, the document you pointed to shows how littleFS detects the bad blocks and tries to recover. Not sure if error detection stuff in the chip would actually help out or not. If it were me I would probably KISS it and maybe ignore the ECC bad block stuff.
 
Sorry it may be beyond my pay grade ;) But as mentioned, the document you pointed to shows how littleFS detects the bad blocks and tries to recover. Not sure if error detection stuff in the chip would actually help out or not. If it were me I would probably KISS it and maybe ignore the ECC bad block stuff.

thanks Kurt. Thats kind of what I was thinking as well but think its going to be Paul's call.
 
thanks Kurt. Thats kind of what I was thinking as well but think its going to be Paul's call.

Pulled that link up quickly before leaving earlier - looked like a better formatted version of the GITHUB .MD one/both if the info files.

So not having read that "above KurtE's paygrade" section - or having any insight into the ECC/BadBlock - if it can be usable and punted that gives Paul the options to : Excluded NAND ( :( ), go without that feature, or help resolve it for inclusion.

So far the chips here have worked without the ECC / BMM as written by mjs513.
 
Pulled that link up quickly before leaving earlier - looked like a better formatted version of the GITHUB .MD one/both if the info files.

So not having read that "above KurtE's paygrade" section - or having any insight into the ECC/BadBlock - if it can be usable and punted that gives Paul the options to : Excluded NAND ( :( ), go without that feature, or help resolve it for inclusion.

So far the chips here have worked without the ECC / BMM as written by mjs513.

Right now ECC is enabled but BBM is not enforced :) Basically right now it lets me know when I messed something up with devel code - when I see ECC errors I go check what I did. Right now its pretty stable.
 
@defragster - @KurtE
Just pushed a minor change to the readECC function in the lib to correct an addressing issue that was bothering me. Yes I am feeling better now.
 
Cannot get littleFS which I downloaded of github yesterday to build for teensy 4.1. Since I don't really need a filesystem, I have been trying SPIMemory.
SPIMemory works for the default channel and the flash chip on the propshield but for the flash on the back of the Teensy4.1 I think I need:

SPIFlash flash2(51,&SPI2);

and program seems to hang in flash2.begin();

Has anyone confirmed this to work for the winbond flash on back of teensy 4.1?
 
Cannot get littleFS which I downloaded of github yesterday to build for teensy 4.1. Since I don't really need a filesystem, I have been trying SPIMemory.
SPIMemory works for the default channel and the flash chip on the propshield but for the flash on the back of the Teensy4.1 I think I need:

SPIFlash flash2(51,&SPI2);

and program seems to hang in flash2.begin();

Has anyone confirmed this to work for the winbond flash on back of teensy 4.1?

Not sure what version was downloaded? Also was it on TeensyDuino 1.54 Beta #5?

As far as flash on underside access - those pins are designed for use with QSPI - QUAD not normal SPI. When setup for QSPI access the FLASH reads directly with memory address references and the MCU handles the addressing and overhead to read the desired locations. Writes do take helper functions to enable that process. But enabling the QSPI takes some .begin commands to enable that, they are incorporated in the LFS startup.

There are examples of that and that is how LittleFS works with those functions available to the low level LFS code for block read and write.

PJRC has a version of the LFS - maybe that is what was used? It was working when last used - but has evolved some for new chip support.

The current version supporting NAND as well as the prior NOR flash chips - not sure what is use there ? - is github.com/Defragster/LFSintegrity/tree/PlusNAND
that has been tested to work with the TD 1.54 b5 release.

Easiest and best supported path to use would be LittleFS unless manual personal effort is desired.

Also good would be trying it and posting any errors or problems seen as there may be something missing that is needed. There is an LFSintegrity sketch in the above linked github that should build and work and give example code for simple file operations as used to test the underlying code from a high level.
 
Using TeensyDuino 1.53, I don't see QSPI library in that (maybe I'm not looking in the right place). I see a lot of recent changes to pjrc website, and now I can't find where to download Teensyduino anymore. Not sure if I want to risk changing to beta with my current project nearly complete. SPI memory access needs are low bandwidth and simple for logging so don't really need a file system. Using Windbond W25Q16JV-DTR, I don't see anthing in data sheet to tell me if its NAND or NOR. The library.properties files says LittleFS is version=0.1.0, which sounds very preliminary and the number of build errors I saw backs that up.
 
Using TeensyDuino 1.53, I don't see QSPI library in that (maybe I'm not looking in the right place). I see a lot of recent changes to pjrc website, and now I can't find where to download Teensyduino anymore. Not sure if I want to risk changing to beta with my current project nearly complete. SPI memory access needs are low bandwidth and simple for logging so don't really need a file system. Using Windbond W25Q16JV-DTR, I don't see anthing in data sheet to tell me if its NAND or NOR. The library.properties files says LittleFS is version=0.1.0, which sounds very preliminary and the number of build errors I saw backs that up.

First the W25Q16JV-DTR is a NOR Flash chip, yes I know that the datasheet is silent on it but if you do a searching you will find that Mouser and Winbond shows it as a NOR flash. Second if you don't include the "LittleFS.h" you won't be using that library in you sketch and you won't be using a FileSystem with that flash chip. You can continue to use SPIMemory in your sketch.

Hope this answers your question?

In your prior post you mentioned using SPI2, unfortunately you can't really use it for Serial Flash chips using the underside pins unless you are breaking the connections out to a castellated board or in some other manner. Those underside pins for the PSRAM and FLASH are really meant to be used for QSPI access.
 
Using TeensyDuino 1.53, I don't see QSPI library in that (maybe I'm not looking in the right place). I see a lot of recent changes to pjrc website, and now I can't find where to download Teensyduino anymore. Not sure if I want to risk changing to beta with my current project nearly complete. SPI memory access needs are low bandwidth and simple for logging so don't really need a file system. Using Windbond W25Q16JV-DTR, I don't see anthing in data sheet to tell me if its NAND or NOR. The library.properties files says LittleFS is version=0.1.0, which sounds very preliminary and the number of build errors I saw backs that up.

LittleFS is NEW to TD 1.54 in beta as noted in p#771. Not sure if it works on TD 1.53 with the addition of the library also noted in p#771 or the current code on PJRC under LittleFS it is copied from before most recent edits.

The TD 1.54 Beta is linked on post under Announcements Forum. The released TD 1.53 is in the same place it was under TeensyDuino software and IIRC that is now linked on each Teensy product page.

The LittleFS is indeed on initial alpha/beta development version. It has been tested to work well by some # of us in development and with proper install it build without errors or problems and tests show it working. It is new as noted to TD 1.54 and there may be CORES changes to allow it to work not in TD 1.53?

Most typical SMALL FLASH 8MB-32MB are common NOR - NAND's are typically larger and indeed are only recently supported in updates in the p#771 github not the last TD 1.54 beta 5 release.

The NOR Flash have had support capable in TD 1.53 - but takes the extra work shown in examples that were done for testing to orchestrate writes as noted and shown in those examples - most may be in the extmem or SPIFFS related earlier works.
 
Back
Top