NAND flash support in 1.54

flexspi_ip_write in the current GitHub code is definitely wrong, looks like a copy/paste error?
 
Actually a couple of errors. It appears that after I got it working and did the IDE save it didn't save all the changes. Not sure what happened. What you see was me playing around before i put it back.

@defragster - where are the instructions to use sublimeText - TyCommander and IDE? Think its time.

Here is the corrected copy and will push:
 

Attachments

  • NAND_SPI_TEST.zip
    9.2 KB · Views: 74
@defragster
After corrections:
Code:
Begin Init

Found W25N01G Flash Chip
0

Status of reg 0xa0: 
(HEX: ) 0x00, (Binary: )0

18
Status of reg 0xb0: 
(HEX: ) 0x18, (Binary: )11000


w25n01g_programDataLoad
w25n01g_programExecute
Reading Data
Write Page Addr Complete
READING DATA START
Command 14 Complete
CHECKING ECC-CODE

[B]0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, [/B]

DEADBEEFdeadbeef
w25n01g_programDataLoad
w25n01g_programExecute
Reading Data
READING DATA START
Command 14 Complete
CHECKING ECC-CODE

[B]0x44[D], 0x45[E], 0x41[A], 0x44[D], 0x42[B], 0x45[E], 0x45[E], 0x46[F], 0x64[d], 0x65[e], 0x61[a], 0x64[d], 0x62[b], 0x65[e], 0x65[e], 0x66[f], 0x0a
], 0x00[[[/B]
 
@mjs513 - github NAND update pushed?

Let me know where you are on Sublime Text integration. The batch files are easy - the work to trigger their execution hopefully documented - it is a bit of menu searching.
 
Awesome work @mjs513

See: github.com/Defragster/Tset

I think it links to Forum?

Let me know ...

@defragster - thanks. But the credit for finding the issue that resulted in getting it to work goes to @ecurtz with the bug to writeRegisterFunction and correction for the addr's.

Doing some clean up now. Still have no clue on bad block management and how to use - its clear as mud :)
 
@defragster - thanks. But the credit for finding the issue that resulted in getting it to work goes to @ecurtz with the bug to writeRegisterFunction and correction for the addr's.

Doing some clean up now. Still have no clue on bad block management and how to use - its clear as mud :)

YES @ECURTZ ... Awesome work! ... I thought of that as soon as I hit 'post reply' - but didn't see the change yet :)
 
Happy to contribute a little. It will be useful to have the support in the official library, so win / win. I think I've successfully read the bad block tables with my normal SPI code, but I haven't ever seen any data in them so it's hard to be sure if everything is as expected.
 
Back and got github ... Opps:
In file included from T:\tCode\T_4.1\extNAND_t41\NAND_SPI_TEST.ino:1:0:
T:\TEMP\arduino_build_NAND_SPI_TEST.ino\sketch\defines.h:112:5: error: 'flashSector_t' does not name a type
flashSector_t sectors; // Count of the number of erasable blocks on the device
^
T:\tCode\T_4.1\extNAND_t41\driver.ino: In function 'bool w25n01g_startup()':
T:\tCode\T_4.1\extNAND_t41\driver.ino:98:14: error: 'flashGeometry_t {aka struct flashGeometry_s}' has no member named 'sectors'
geometry.sectors = 1024; // Blocks
^
T:\tCode\T_4.1\extNAND_t41\driver.ino:103:57: error: 'flashGeometry_t {aka struct flashGeometry_s}' has no member named 'sectors'
geometry.totalSize = geometry.sectorSize * geometry.sectors;
^
T:\tCode\T_4.1\extNAND_t41\driver.ino: In function 'void w25n01g_deviceErase()':
T:\tCode\T_4.1\extNAND_t41\driver.ino:139:47: error: 'flashGeometry_t {aka struct flashGeometry_s}' has no member named 'sectors'
for (uint32_t block = 0; block < geometry.sectors; block++) {
^
T:\tCode\T_4.1\extNAND_t41\driver.ino: In function 'void w25n01g_randomProgramDataLoad(uint16_t, const uint8_t*, int)':
T:\tCode\T_4.1\extNAND_t41\driver.ino:172:68: warning: invalid conversion from 'const void*' to 'void*' [-fpermissive]
flexspi_ip_read(14, flashBaseAddr + columnAddress, data, length);
^
T:\tCode\T_4.1\extNAND_t41\NAND_SPI_TEST.ino:71:6: note: initializing argument 3 of 'void flexspi_ip_read(uint32_t, uint32_t, void*, uint32_t)'
void flexspi_ip_read(uint32_t index, uint32_t addr, void *data, uint32_t length)
^
exit status 1
 
Oops deleted one too many lines.

Just add the following line to before the geometry structure in defines.h
Code:
//
typedef uint16_t flashSector_t;
Going to push the fix up now.
 
Got github updated file. Extended the beefy[] as it was less than 20 so compiler warning.

And in either case it isn't reading it back right :( - but it compiles.
Code:
Begin Init
Found W25N01G Flash Chip
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
DEADBEEFdeadbeef80085
0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0xff[�], 0x00[
 
Got github updated file. Extended the beefy[] as it was less than 20 so compiler warning.

And in either case it isn't reading it back right :( - but it compiles.

Funny, it doesn't like using the short cut load - pageProgram. If you change beefy load to:
w25n01g_writeEnable(true); //sets the WEL in Status Reg to 1 (bit 2)
w25n01g_programDataLoad(W25N01G_LINEAR_TO_COLUMN(4000), buffer, 20);
//w25n01g_randomProgramDataLoad(W25N01G_LINEAR_TO_COLUMN(40000), buffer, 16);
w25n01g_programExecute(W25N01G_LINEAR_TO_PAGE(4000));
//w25n01g_pageProgram(4000, buffer, 20);

EDIT:
Code:
Begin Init

Found W25N01G Flash Chip

0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

DEADBEEFdeadbeef
0x44[D], 0x45[E], 0x41[A], 0x44[D], 0x42[B], 0x45[E], 0x45[E], 0x46[F], 0x64[d], 0x65[e], 0x61[a], 0x64[d], 0x62[b], 0x65[e], 0x65[e], 0x66[f], 0x0a[
], 0x00[
 
All
For now don't use the following 2 functions:
Code:
w25n01g_randomProgramDataLoad
w25n01g_pageProgram

Reason: If we use randomProgram doesn't seem to update to the new column address so have to read up a bit more. pageProgram does work the way i thought - my fault. Think because it was meant for something else.

UPDATE:
@defragster - @ecurtz
Just pushed a change to fix randomProgramDataLoad function. Dumb typo on my part. Think eyes were crossed when i typed it.

pageProgram is something else.
 
Last edited:
Got it - after spare ' ' in 4 000 from post fixed

Code:
Begin Init
Found W25N01G Flash Chip
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
DEADBEEFdeadbeef80085
0x44[D], 0x45[E], 0x41[A], 0x44[D], 0x42[B], 0x45[E], 0x45[E], 0x46[F], 0x64[d], 0x65[e], 0x61[a], 0x64[d], 0x62[b], 0x65[e], 0x65[e], 0x66[f], 0x38[8], 0x30[0], 0x30[0], 0x38[8], 0x00[
{ can't copy paste the rest of the zero [] chars }
 
So far used buffered reads tomorrow will test continuous reads/writes which make it more Nor flash like. But think done for today.
 
On and off here today - missed this by 3 hours ... awesome groundwork - There Is Life!

And we have three T_4.1's with NAND's on board and no solder casualties! Seems Paul picked a suitable first chip and made good room for it on the T_4.1 PCB! As shown in p#33 just enough clearance to the CAP on the side.

Managed to get it taped on straight on the first try to solder side #1! New 0.025" MG lead solder gives the right amount - but short on flux this solder paste flux did a great job breaking the surface tension to ball up on the exposed chip solder point.

Now to start speed and integrity testing :) It is running on the same slower 88 MHz PSRAM clock speed?

Might modify Paul's PSRAM test? What is the start address the nandFlash?: flashBaseAddr = 0x01000000
Code:
static const uint32_t flashBaseAddr = 0x01000000u;
static const uint32_t psramAddr =     0x70000000;

It is 0x08000000 big or 134,217,728 bytes [128KB] - if it really has one GigaBits - so that would still work with PSRAM?
 
@defragster - Good Morning.

It is running on the same slower 88 MHz PSRAM clock speed?
Yes its running at the same clock speed as the PSRAM. If i remember right the max speed is 104Mhz.

Might modify Paul's PSRAM test? What is the start address the nandFlash?: flashBaseAddr = 0x01000000
Same same for start address.

so that would still work with PSRAM?
Should still work with a PSRAM installed.
 
Great work! Mine should arrive on Friday ;) Just in time not to help :D
(But at least the package will also include a new RPI4 8MB)
 
@KurtE
Don't worry - still plenty I don't understand about this chip - Bad Block management and memory addressing :)

Just pushed an up that will hopefully simplify the interface a bit and did a bit more clean up. This is a work in progress but at least its a starting point.
 
@defragster
Forgot to mention - designed so you start you addressing at 0. No need to account for flashbaseaddr - done in software :)

EDIT:
Oh forgot the most important thing - doesn't support direct memory addressing for writes. Everything goes through the data buffer :(
 
Last edited:
Added check42:
Code:
Begin Init

Found W25N01G Flash Chip

0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

DEADBEEFdeadbeef
0x44[D], 0x45[E], 0x41[A], 0x44[D], 0x42[B], 0x45[E], 0x45[E], 0x46[F], 0x64[d], 0x65[e], 0x61[a], 0x64[d], 0x62[b], 0x65[e], 0x65[e], 0x66[f], 0x0a[
], 0x00[


    NAND ========== memory map ======  ====== check42() : WRITE !!!!
		NAND length 0x8000000 element size of 1
	 took 5222454 elapsed us
    NAND ============================ check42() : COMPARE !!!!
	 took 4752294 elapsed us
Good, 	Found 42 in NAND 0x8000000 Times
One difference from our old version - did reads and writes in blocks of 2048. Took way too long for 1 byte reads and writes with this size memory chip.

Remember no direct memory writes.
 
Awesome work @Mjs513! This is more work than was done to prove and show usage of the NOR_Flash - except for SPIFFS.

Amazing it takes 5.2 sec for 128MB write of #42, and the READ compare is 4.7 sec - expected READ to be significantly faster?

Though that is 24.6 MB/s WRITE and 27.3 MB/s READ

Pushed up sketch edits:
Code:
Begin Init
Found W25N01G Flash Chip
[B]    NAND ============================ check42() : COMPARE !!!!
	 took 4752784 elapsed us
Good, 	Found 42 in NAND 0x8000000 Times[/B]
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
DEADBEEFdeadbeef4321
0x44:D 0x45:E 0x41:A 0x44:D 0x42:B 0x45:E 0x45:E 0x46:F 0x64:d 0x65:e 0x61:a 0x64:d 0x62:b 0x65:e 0x65:e 0x66:f 0x34:4 0x33:3 0x32:2 0x31:1 0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  0x00:  


    NAND ========== memory map ======  ====== check42() : WRITE !!!!
		NAND length 0x8000000 element size of 1
	 took [B]5222452 elapsed us[/B]
    NAND ============================ check42() : COMPARE !!!!
	 took [B]4752878 elapsed us[/B]
Good, 	Found 42 in NAND 0x8000000 Times

Add/Edit for Check42( false ) to compare on setup start - to confirm NAND Flash data integrity from prior run of code doing Check42( true ) on prior run.
> changed beefy print loop to not print 0x0 chars, and removed extra chars for compressed output
> extended beefy[] string to prevent compiler warning on exceeding array bounds with loop to 20
> Hit SublimeText AutoFormat that re-spaced the code
 
Thanks for testing @defragster and doing the sketch updates

Actually did the same thing putting a check42 at the beginning of the sketch but didn't make it permanent.

Not sure what else to do with it right now until we figure out if we are gong to use SPIFFS or some other file system. But think that will come soon enough. But at least we know it works. :)
 
After all the 'heavy lifting' you did ... it was the 'least' I could do :) Have not even looked under the covers of the "magic" calls ...

Any understanding why the writes are so close to reads in speeds? Is writing that efficient - or reading somehow hobbled?

Interesting that all 128KB ( 0x8000000==134,217,728 Bytes ) is 100% error free? Either the chip maps out bad blocks - or these are all perfect?

Would be cool - ( yeah I not should say this if not prepared to do it myself ) - if that sketch could run the same whether NOR or NAND was detected?
That would allow quick test of either and comparison of speed.
 
According to the datasheet writing within the chip is approximately 10x slower than reading, but I'm not sure how much of the time is the transfer which is probably the same speed either way. I suspect a lot of the read/write overhead might just be that it's looping through everything 4 bytes at a time. Doing it with DMA would be a better comparison (and allows them to be sort of asynchronous as well.)
 
Back
Top