Forum Rule: Always post complete source code & details to reproduce any issue!
Page 33 of 34 FirstFirst ... 23 31 32 33 34 LastLast
Results 801 to 825 of 831

Thread: LittleFS port to Teensy/SPIFlash

  1. #801
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Teensy LC Issue with LittleFS

    @Frank B asked about if we did any testing with Teensy LC (https://forum.pjrc.com/threads/64592...l=1#post266527) so I hooked up a LC to the littlefs_teensy_test1a sketch using a W25Q64FV to start and the sketch hangs on the first:
    Code:
      file = myfs.open("structureData1/temp_test.txt", FILE_WRITE);
    the preceding code seems to work to create the file and the directory:
    Code:
    LittleFS Test
    TotalSize (Bytes): 8388608
    ...............
    started
    MAKE files
    printDirectory
    --------------
    DIR	structureData1 / 
    
     0 dirs with 0 files of Size 0 Bytes
    I did a erase just in case.

    As a sanity check I ran SerialFlash BenchMark:
    Code:
    Raw SerialFlash Hardware Test
    
    Read Chip Identification:
      JEDEC ID:     EF 40 17
      Part Nummber: W25Q64FV
      Memory Size:  8388608 bytes
      Block Size:   65536 bytes
    
    Reading Chip...
    
    Writing 4096 signatures
    
    Double Checking All Signatures:
      all 4096 signatures read ok
    
    Checking Signature Pairs
      all 2047 signature pairs read ok
    
    Checking Read-While-Write (Program Suspend)
      write 256 bytes at 256
      write time was 405 microseconds.
      read-while-writing: 00 00 00 00 15 F5 95 4B 
      test passed, good read while writing
    
    Checking Read-While-Erase (Erase Suspend)
      erase time was 172754 microseconds.
      erase correctly erased 65536 bytes
      read-while-erasing: 00 00 00 00 15 F5 95 4B 
      test passed, good read while erasing
    
    All Tests Passed  :-)
    
    Test data was written to your chip.  You must run
    EraseEverything before using this chip for files.
    Just to make sure.
    Last edited by mjs513; 01-16-2021 at 02:35 PM. Reason: Found the link

  2. #802
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,514
    @mjs513 Sounds like you have been busy!

    What about Teensy 2? (Just kidding)

  3. #803
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,995
    Quote Originally Posted by mjs513 View Post
    Code:
    All Tests Passed  :-)
    Just to make sure.
    Nice

  4. #804
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Quote Originally Posted by KurtE View Post
    @mjs513 Sounds like you have been busy!

    What about Teensy 2? (Just kidding)
    MOrning @KurtE
    A bit. Hate leaving things hanging so I had to finish off the BBM stuff (not much more I can do on that) and test the LC I just remembered. Going to do a few more tests just in case

  5. #805
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Quote Originally Posted by Frank B View Post
    Nice
    Not nice . That was with SerialFlash not LittleFS. LittleFS seems to be having a problem with LC.

  6. #806
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Another data point. Just ran my bench sketch for read/write and that seemed to work except totalSize is returning 0!
    Code:
    LittleFS Test
    .........................................................................................................................
    started
    Disk Stats:
    Bytes Used: 8192, Bytes Total:0
    Benchmark:
    FILE_SIZE_MB = 1
    BUF_SIZE = 2048 bytes
    Starting write test, please wait.
    
    write speed and latency
    speed,max,min,avg
    KB/Sec,usec,usec,usec
    102.53,25372,16442,19975
    102.67,25351,16385,19944
    
    Starting sequential read test, please wait.
    
    read speed and latency
    speed,max,min,avg
    KB/Sec,usec,usec,usec
    507.84,6912,2980,4031
    507.84,6913,2981,4031
    
    Done
    So something funny going on with LC and LittleFS.

  7. #807
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Ok figured out the problem and its not LittleFS. Problem is just running out of memory within the sketch. There are a few array of 2048 and while by itself is not bad, add that with the sketch size probably causing an issue. I reduced the size of one of the arrays from 2048 to 512 and it worked as it should:
    Code:
    LittleFS Test
    TotalSize (Bytes): 8388608
    started
    MAKE files
    printDirectory
    --------------
    FILE	0_2MBfile.txt		2048000
    DIR	structureData1 / 
    	FILE	temp_test.txt		171
    
     0 dirs with 1 files of Size 171 Bytes
    FILE	temp_test1.txt		171
    FILE	temp_test2.txt		152
    FILE	temp_test3.txt		6144
    
     1 dirs with 4 files of Size 2054467 Bytes
    
    printDirectory
    --------------
    FILE	0_2MBfile.txt		2048000
    DIR	structureData1 / 
    	FILE	temp_test.txt		190
    
     0 dirs with 1 files of Size 190 Bytes
    FILE	temp_test1.txt		190
    FILE	temp_test2.txt		171
    FILE	temp_test3.txt		6144
    
     1 dirs with 4 files of Size 2054505 Bytes
    
    --------------
    printDirectory
    --------------
    FILE	0_2MBfile.txt		2048000
    DIR	structureData1 / 
    	FILE	temp_test.txt		190
    
     0 dirs with 1 files of Size 190 Bytes
    FILE	temp_test1.txt		190
    FILE	temp_test2.txt		171
    FILE	temp_test3.txt		7168
    
     1 dirs with 4 files of Size 2055529 Bytes
    
    Disk Usuage:
    Bytes Used: lu, Bytes Total:lu
    Test for SOME DATA TO TEST
    Don't think %llu is supported on the LC though

    Ok now to see if I can find my audio board to test wavfileplayer

  8. #808
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    @Frank B
    Now that I know LittleFS works with LC I started looking at wavPlayer sketch. Think a few files are going to have modified especially play_sd_wav.cpp

  9. #809
    Member
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    27
    Hi
    I have installed the beta 5 and tested ListFiles example in LittleFS on my Macronix MX25L12835F chip.
    Result is : initialization failed.
    I run on T4.0 and everything works OK using the SerialFlash lib.

    I suspect that the chip gives the wrong Id ???

    Are there any plans of adding more chips?

    /Tomas

  10. #810
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Quote Originally Posted by kets View Post
    Hi
    I have installed the beta 5 and tested ListFiles example in LittleFS on my Macronix MX25L12835F chip.
    Result is : initialization failed.
    I run on T4.0 and everything works OK using the SerialFlash lib.

    I suspect that the chip gives the wrong Id ???

    Are there any plans of adding more chips?

    /Tomas
    Right now LittleFS does not support the Macronix MX25L12835F chip it only supports the following based on the table in the .cpp file:
    Code:
    	{{0xEF, 0x40, 0x15}, 24, 256, 4096, 2097152, 3000, 400000}, // Winbond W25Q16JV*IQ/W25Q16FV
    	{{0xEF, 0x40, 0x16}, 24, 256, 4096, 4194304, 3000, 400000}, // Winbond W25Q32JV*IQ/W25Q32FV
    	{{0xEF, 0x40, 0x17}, 24, 256, 4096, 8388608, 3000, 400000}, // Winbond W25Q64JV*IQ/W25Q64FV
    	{{0xEF, 0x40, 0x18}, 24, 256, 4096, 16777216, 3000, 400000}, // Winbond W25Q128JV*IQ/W25Q128FV
    	{{0xEF, 0x40, 0x19}, 32, 256, 4096, 33554432, 3000, 400000}, // Winbond W25Q256JV*IQ
    	{{0xEF, 0x40, 0x20}, 32, 256, 4096, 67108864, 3500, 400000}, // Winbond W25Q512JV*IQ
    	{{0xEF, 0x70, 0x17}, 24, 256, 4096, 8388608, 3000, 400000}, // Winbond W25Q64JV*IM (DTR)
    	{{0xEF, 0x70, 0x18}, 24, 256, 4096, 16777216, 3000, 400000}, // Winbond W25Q128JV*IM (DTR)
    	{{0xEF, 0x70, 0x19}, 32, 256, 4096, 33554432, 3000, 400000}, // Winbond W25Q256JV*IM (DTR)
    	{{0xEF, 0x70, 0x20}, 32, 256, 4096, 67108864, 3500, 400000}, // Winbond W25Q512JV*IM (DTR)
    	{{0x1F, 0x84, 0x01}, 24, 256, 4096, 524288, 2500, 300000}, // Adesto/Atmel AT25SF041
    	{{0x01, 0x40, 0x14}, 24, 256, 4096, 1048576, 5000, 300000}, // Spansion S25FL208K
    	//FRAM
    	{{0x03, 0x2E, 0xC2}, 24, 64, 128, 1048576, 250, 1200},  //Cypress 8Mb FRAM
    	{{0xC2, 0x24, 0x00}, 24, 64, 128, 131072, 250, 1200},  //Cypress 1Mb FRAM
    	{{0xC2, 0x24, 0x01}, 24, 64, 128, 131072, 250, 1200},  //Cypress 1Mb FRAM, rev1
    	{{0xAE, 0x83, 0x09}, 24, 64, 128, 131072, 250, 1200},  //ROHM MR45V100A 1 Mbit FeRAM Memory
    	{{0xC2, 0x26, 0x08}, 24, 64, 128, 131072, 250, 1200},  //Cypress 4Mb FRAM
    and large Winbond NAND Chips:
    Code:
    	{{0xEF, 0xAA, 0x21}, 24, 2048, 131072, 131596288,   2000, 15000},  //Winbond W25N01G
    	{{0xEF, 0xAA, 0x22}, 24, 2048, 131072, 265289728, 2000, 15000},  //Winbond W25N02G
    	{{0xEF, 0xBB, 0x21}, 24, 2048, 131072, 265289728, 2000, 15000},  //Winbond W25M02
    	{{0xEF, 0xBB, 0x21}, 24, 2048, 131072, 258998272, 2000, 15000},  //Winbond W25M02
    There are no specific plans at the moment to support additional chips but I am sure the list will grow over time. Remember LittleFS is still what you might say is in beta testing and was only just released in TD1.54beta-5 and has since been updated a few times.

    SerialFlash is still operational and there is a possibility that it may be ported over to LittleFS but do not believe that has been decided yet.

    Just as a note I checked Digikey and there is a note on the Macronix MX25L12835F page that you should be aware of:
    Not Recommended for New Design,

  11. #811
    Member
    Join Date
    Mar 2019
    Location
    Sweden
    Posts
    27
    OK, thank's for your answer.
    I'm aware of the not for new designs message.
    The solution is ofcause to switch over to a supported one.
    Will look in the list for someone with compatible layout: 8SOIC with at least 128KB

    /Tomas

  12. #812
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    376
    Quote Originally Posted by mjs513 View Post
    @Frank B
    Now that I know LittleFS works with LC I started looking at wavPlayer sketch. Think a few files are going to have modified especially play_sd_wav.cpp
    @mjs513 - Not sure if you ever had time to play with the wavPlayer sketch yet. I have LittleFS initially working with it. I chose to start testing with LittleFS_SPINAND using chipSelect = 4. Admittedly I am still trying to digest all of the methods needed to access the various memories available on the T4.1 and PJRC memory board. I got an audio board Rev D from PJRC and used it with the breakout board and memory board. I updated the latest TD with your LittleFS library. The next challenge was writing a sketch to copy the test wav files from a SD card to the NAND chip. So I modified a file copy sketch that I use to copy files between SDIO, and external SPI SD cards to use LittleFS. This worked well.

    One thing I ran into was having to use a 'extern' declaration for this:
    Code:
    extern LittleFS_SPINAND myfs;  // Not sure how to avoid this declaration???
    This is line #49 in 'play_littleFS_wav.cpp' which is defined in line #39 of 'littleFSWavPlayer.ino'. The original WavFilePlayer used 'SD.begin()' in the '.ino' and 'SD.open()' in 'play_SD_wav.cpp'. Just have not had enough time to understand LittleFS yet

    Anyway here is the link to the repository if anybody wants to play:
    https://github.com/wwatson4506/littleFSWavPlayer

  13. #813
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    @wwatson
    Started working on the changes but ran into a problem when I posted the issue Paul mentioned that he wanted to modify the wavFilePlay in the library to make it more generic so kind of put it on hold. Can't find that post right now.

  14. #814
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    376
    Quote Originally Posted by mjs513 View Post
    @wwatson
    Started working on the changes but ran into a problem when I posted the issue Paul mentioned that he wanted to modify the wavFilePlay in the library to make it more generic so kind of put it on hold. Can't find that post right now.
    You are right. I remember that post as well. Completely forgot about it. Oh well, at least I know it works. Right now I guess a lot of things are still up in the air and I have a tendency to jump the gun. It still gave me a chance to play with LittleFS and take a break from working with SdFat and MSC. I think I am finally figuring out which memory chips are what and how to access them using all of the test programs. The big one was the chip selects I modified my copy program that allows me to copy files between all available storage devices on for the Teensies to work with LittleFS. So far, the memory chips I have tested with LittleFS seem to work. That is how I copied the audio test files to the SPINand chip on the mem board from a USB thumb drive.

  15. #815
    Very good news it has already being proven to play audio with LittleFS. I am curious about how the read speed would perform for NAND chips over QSPI in comparison with the current NOR over SPI. AFAIK QSPI should increase read speeds, but NAND is slower than NOR in read operations. I don't know if LittleFS would take a part in read speeds as well.

  16. #816
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    @defragster
    Was trying out your new and improved LFSIntegrity.ino and wanted to test the 25Q512 Winbond flash. Did a lowlevel format and really really long using the memory breakout board:
    Code:
    ?[  0.06 M](0.05941 M elap) Awaiting input 0123456789RdcghkFqvplmusSBbyYxfan+-? loops left 0 >
    Formatting Low Level:
    	.........................................................................................................................
    
     Done Formatting Low Level in 345834838 us.
    u 
    	 Updated filecount 0
    F
    printDirectory SPI_DISK
    --------------
    
     0 dirs with 0 files of Size 0 Bytes
     Total 0 files of Size 0 Bytes
    Bytes Used: 8192, Bytes Total:67108864
    On the 25Q128
    Code:
    Formatting Low Level:
    	.........................................................................................................................
    
     Done Formatting Low Level in 116834058 us.
    u 
    	 Updated filecount 0
    F
    printDirectory SPI_DISK
    --------------
    
     0 dirs with 0 files of Size 0 Bytes
     Total 0 files of Size 0 Bytes
    Bytes Used: 8192, Bytes Total:16777216
    Now I know the NAND formatting is implemented differently but just for comparison:
    Code:
    Formatting Low Level:
    	..............................................................................................................................
    
     Done Formatting Low Level in 7203155 us.
    u 
    	 Updated filecount 0
    F
    printDirectory SPI_NAND
    --------------
    
     0 dirs with 0 files of Size 0 Bytes
     Total 0 files of Size 0 Bytes
    Bytes Used: 262144, Bytes Total:131596288
    EDIT: just a note if you do a quick format no issue - goes really fast

  17. #817
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,505
    About Formatting - yeah it is slow. 'F' has a provision for block by block feedback to SerialUSB, 'f' does not. To see signs of life in 'f' uncomment this LFSIntegrity line: #define SHOW_YIELD_CNT 1

    These both present fully erased media - with loss of the LFS 'history' as it keeps it of block reuse for wear leveling. A fresh LFS will always restart using the same initial blocks:
    'q' : Quick Format :: myfs.quickFormat();
    'F' : Low Level Format :: myfs.lowLevelFormat('.');

    Doing this leaves LFS system unchanged:
    'f' : Reclaim all unused format :: myfs.formatUnused( 0, 0 );

    Both 'f' and 'F' will take some long time proportionate to the number of dirty blocks on the disk they look at and the time it takes for the media to do the block format. They both do the same thing, except 'f' skips over blocks reported in use by LFS to preserve the file system.

    To keep the disk from going stale as LFS discards blocks and progress across the media formatting unused dirty blocks periodically do:
    Code:
    	static uint32_t lastBlock=0;
    ...
    	uint32_t cnt = 5; // pick some number for cnt that will account for disk activity of deletes, or writes where it will cause LFS to discard DIR or FILE blocks to account for the change.
    	lastBlock = myfs.formatUnused( cnt, lastBlock );
    When myfs.formatUnused return 0 it has completed a pass from the last start with lastBlock=0.

    Calling myfs.formatUnused has the overhead of waiting for LFS to parse its directory structure ( proportional to doing a full Directory walk ) to account for all the blocks in use. Noted earlier in this thread that can take some time when there are many files and dirs where the walk has to read all the links.
    >> Current QSPI NOR disk has root and 32 Dirs with 784 files. DirWalk print takes 736ms and a myfs.formatUnused(1,0) looking for a single unformatted unused block on a formatted Used disk takes 276ms.
    >> With 'S' then 's' to make and delete a 2MB file: Dirty Unused blocks a single Format takes only ~90ms. And and a Dirty Unused Format for 15 blocks takes only about 450ms - but it takes 34 of those to restore all the ~500 discarded blocks.

    > With faster NAND format this math changes and the dir overhead is worse and myfs.formatUnused() with not enough to do is a waste of time
    >> started up a 1Gb NAND and a dir quickly was filled in the first iteration with 148 files and the DirWalk took 2.3 seconds across the 33 total dirs.
    >> Doing a DirWalk takes 2.26 seconds and myfs.formatUnused() of 15 blocks takes 6.1 seconds
    >> The 'S' & 's' test only takes 2 sets of 15 myfs.formatUnused() - the first is 2.14 seconds and the second partial is 4.4 seconds

    Some efficiencies could be had - but some would require digging into the internals of the LFS core code. The one .cache element given holds a bitmap they use to track internally used blocks when looking for space. But the lfs_fs_traverse() doesn't use that - it does a full root down block walk.

  18. #818
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    @defragster - @PaulStoffregen

    One thing to remember is that when using LittleFS_SPIFlash you are limited to a SPI Clock of 30Mhz but when using a NAND you can run at 55Mhz SPI Clock.

    There also seems to be another issue that I don't understand.

    In the case of the NAND I can run at 75Mhz SPI clock when using my stand alone NAND library but when using LittleFS seems to fail above 55Mhz which is what it is currently set as. Similarly, but worse is with LittleFS 30Mhz seems to be about the limit for the NOR W25Q512 chip even though the spec says 104Mhz max.

    As a quick a dirty test I just ran a simple test sketch, just getting the JEDEC for the 25Q512 Flash chip and I can only get the correct ID if I run at 30Mhz SPI. So not sure what the problem is with going faster. Here is the sketch if you are interested:
    Code:
    #include <SPI.h>
    
    #define SPICONFIG   SPISettings(40000000, MSBFIRST, SPI_MODE0)
    
    
    void setup() {
      while(!Serial);
      digitalWrite(5, HIGH);
      pinMode(5, OUTPUT);
      SPI.begin();
    
      uint8_t buf[4] = {0x9F, 0, 0, 0};
      SPI.beginTransaction(SPICONFIG);
      digitalWrite(5, LOW);
      SPI.transfer(buf, 4);
      digitalWrite(5, HIGH);
      SPI.endTransaction();
    
      Serial.printf("Flash ID: %02X %02X %02X \n", buf[1], buf[2], buf[3]);
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
    
    }
    The timing table does state that:
    Code:
    Clock frequency for Read Data instruction (03h) has a max SPI clock 50 MHz
    but for the 25Q512 LittleFS is using 0x13 (read 4 byte) which should allow you to go to 104Mhz - I think. I always have problem with datasheets.

    The one note is that I can push the 30Mhz to 45Mhz and it will still work. But at 50Mhz it fails.

  19. #819
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    @PaulStoffregen - @All

    In looking at the code for the 25Q512 you are using 4-byte addressing mode. A quick question though, don't you have to enter 4-byte address mode first like this:
    Code:
    	if(info->addrbits == 32) {
    		port->beginTransaction(SPICONFIG);
    		digitalWrite(pin, LOW);
    		delayNanoseconds(50);
    		port->transfer(0xB7);
    		digitalWrite(pin, HIGH);
    		port->endTransaction();
    	}
    or am I missing something - which is probably the case?

  20. #820
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,505
    Question: is it right to assume that no new block is allocated in LFS without an ERASE?

    Perhaps it can do a partial block update program 'in place' - but it cannot allocate/use a new block without calling 'erase' on it first based on this from LittleFS\src\littlefs\DESIGN.md::
    Code:
     168:     // Erase a block. A block must be erased before being programmed.
      169:     // The state of an erased block is undefined. Negative error codes
      170      // are propogated to the user.
    This was used earlier to some degree to detect disk change and when to trust a bitmap.
    To be fully usable each erase entry point could set a flag on an erase. The flag could be used to determine if allocated blocks were changed since last bitmap update. This could save both the LFS_Traverse time as well as allowing the state of formatted blocks to be known.

    It is perhaps possible that 'deleting' files could Free blocks that only a traverse would detect - where the headers and dir entries for those blocks might take an update showing them free and dirty. But the bitmap would be updated after each complete pass over the blocks to account for that, but without Erase changes it could complete to the last disk block before restarting.

    Given that the formatUnused could often avoid traverse when doing small block groups in a repeat fashion while the media was in use between groups, then on returning would know to update or not the LFS_Traverse bits and keep track safely of where it left off. As noted some time back the traverse can take a significant time.


    ALSO: given every block is validated to be FULLY empty on erase request - the formatUnused checking only the first 32 or 256 bytes should always detect a dirty block - and if not then it would get formatted before use on erase(). That would speed up the unusedFormat a great deal - this was the original process. Even reading 256 bytes would save 15/16 th's of the time now used to detect 'clean' 4096 byte blocks.

  21. #821
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,505
    Updated LFSIntegrity to have a 'w'ipe of files and dirs.

    I'll post code later in the AM - time this AM for a few hours Zzzz's ....

    Massive speed up crossing already formatted blocks for formatUnused()
    Updated LittleFS and LittleFS_NAND:
    Code:
    static bool blockIsBlank(struct lfs_config *config, lfs_block_t block, void *readBuf, bool full=true );
    static bool blockIsBlank(struct lfs_config *config, lfs_block_t block, void *readBuf, bool full )
    {
    	if (!readBuf) return false;
    	for (lfs_off_t offset=0; offset < config->block_size; offset += config->read_size) {
    		memset(readBuf, 0, config->read_size);
    		config->read(config, block, offset, readBuf, config->read_size);
    		const uint8_t *buf = (uint8_t *)readBuf;
    		for (unsigned int i=0; i < config->read_size; i++) {
    			if (buf[i] != 0xFF) return false;
    		}
    		if ( !full )
    			return true; // first bytes read as 0xFF
    	}
    	return true; // all bytes read as 0xFF
    }
    >> This allows formatUnused to check only the first read_size block for 0xFF's and call it good.
    Note 1: any LFS used block starts with HEADER info that seems to contraindicate not having at least on zero bit!
    Note 2: If unusedFormat somehow makes a mistake: No block is used by LFS without requesting a normal FORMAT that will still do a "full" blockIsBlank(,,,full=true) verify and format if needed.

    Quick Preview of a formatted disk - this is a FAST TO FORMAT SPI_NAND disk that is Large at Bytes Total:265,289,728
    'Swf' : make a 2MB file, wipe all files, 'f'ormatUnused :: formatUnused :: Done Formatting Low Level in 1,210,826 us.
    ...versus...
    'SwF' : make a 2MB file, wipe all files, lowLevelFormat :: Done Formatting Low Level in 74,828,860 us.

    THANKS FRANKB - for HardFault detection! - recursive deleteAllDirectory(myfs.open("/"), szNone ); had a couple of issues - and seeing this POP up made fixing them easier than some of the compile errors. Not that the output told me anything other than ... 'Major Issue', which was all I needed combined with the output the preceded it! No HANGS and NO need to push Button!

    @Paul - this needs to be in TD 1.54 Beta 7 - Please!
    Code:
    Hardfault.
    Return Address: 0x863B0C48
    	(IACCVIOL) Instruction Access Violation
    Code:
    Hardfault.
    Return Address: 0x1153A
    	(DACCVIOL) Data Access Violation
    	(MMARVALID) Accessed Address: 0x0 (nullptr)
    BTW: New computer tuned up and working very well! SublimeText and TSET working thanks to github and forum notes.

  22. #822
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,505
    @mjs513 - KurtE - Paul ... @all:

    Just pushed up an update to : github.com/Defragster/LFSintegrity

    In the process the NAND branch was deleted. { New machine new entry to github - still stuck on some Pull Request for changes not here ??? }

    INTENDED UPDATES:
    > LFSIntegrity as it is here - updated from Beta 6 release that had some extras/issues

    > LFS and NAND
    - > code as it was here
    - > edit to formatUnused to do a quick out on blockIsBlank() as noted in p#821

    > Add T_4.1 folder to extras for common quick test

    > It does include at least on edit to the 'lookAhead' size ... This will use RAM but should allow LFS to hold whole media bitmap - assuming it keeps it up to date and doesn't re-read it by traverse

    @mjs513 - please do a code compare if possible to assure I didn't have any other tweaks/edits no in line with your current?

    Here is what change to formatUnused does on SPI NAND in LFSIntegrity with : "BSwf"
    Code:
    Start Big write of 132493312 Big write /0_bigfile.txt took 136.52 Sec for 132491264 Bytes : file3.size()=132491264
    	Big write KBytes per second 970.48 
    
    Start Big write of 2048000 Bytes.........................
    Big write /0_2MBfile.txt took  2.15 Sec for 2048000 Bytes : file3.size()=2048000
    	Big write KBytes per second 950.73 
    
    Wipe All Files and DIRS:
    	Removed>	0_2MBfile.txt
    	Removed>	0_bigfile.txt
    
     myfs.formatUnused( 0 ) ...
    	 formatUnused :: Done Formatting Low Level in 2,590,362 us.
    And for LLformat of the same: "BSwF"
    Code:
    Start Big write of 132493312 Big write /0_bigfile.txt took 137.88 Sec for 132491264 Bytes : file3.size()=132491264
    	Big write KBytes per second 960.89 
    
    Start Big write of 2048000 Bytes.........................
    Big write /0_2MBfile.txt took  2.15 Sec for 2048000 Bytes : file3.size()=2048000
    	Big write KBytes per second 950.70 
    
    Wipe All Files and DIRS:
    	Removed>	0_2MBfile.txt
    	Removed>	0_bigfile.txt
    
    Formatting Low Level:
     Done Formatting Low Level in 39,053,222 us.

  23. #823
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    @defragster- @KurtE
    NAND Branch if I remember correctly was incorporated into LittleFS packaged with beta6, so that should be the latest. I will take a look and let your know.

    The only change is to blockisBlank correct?
    Last edited by mjs513; 02-18-2021 at 12:37 AM.

  24. #824
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,505
    Yes, the meaningful change is to blockisBlank() in two places ( NAND and LFS other) and the call change in formatUnused.

    I had a good compare post of the times - forgot to post as I ran off - came back with more info accumulated ... messed up and just deleted ...

    <edit>: and of course edits to LFSIntegrity ...
    Last edited by defragster; 02-18-2021 at 01:18 AM.

  25. #825
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,374
    Quote Originally Posted by defragster View Post
    Yes, the meaningful change is to blockisBlank() in two places ( NAND and LFS other) and the call change in formatUnused.

    I had a good compare post of the times - forgot to post as I ran off - came back with more info accumulated ... messed up and just deleted ...

    <edit>: and of course edits to LFSIntegrity ...
    @defragster
    Just did the code compare and looks good for NAND. See there are 2 constructors now for blockisBlank in NAND.cpp and that was it for the changes in NAND.cpp. Other than I had some Serial prints uncommented that was it.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •