Managing NAND Flash Memory Column Addresses and Bad Blocks

Thread Starter

Nikola Ristic

Joined Aug 27, 2019
2
Hello,

I am working with TOSHIBAs NAND flash memory. I am using standard SPI protocol to communicate with it. The datasheet is in the link below. I am trying to understand and solve two problems:

1. I do not understand what exactly is the column address of a NAND flash memory. On page 4 of the datasheet it is said that a column address is the byte location within a page and that the page is the smallest addressable unit for reading and writing data. Since pages are located in blocks of the memory, shouldn't that mean I only need the address of the block and page from which I need to read data/ to which i need to store data? Also, if a page is the smallest addressable unit for reading and writing, how am I able to write (and read) only into specific byte locations of the page by specifying the column address in the SPI transaction sequence needed for the given operations (That means that a page is actually not the smallest addressable unit for writing and reading data. Instead, a byte within a page is the smallest addressable unit)? In summary, i need to understand what the column address is used for and why am I able to write data into specific byte locations of a page since a page is the smallest addressable unit for writing and reading.

2. I am having trouble identifying bad blocks. The reason is that i do not understand from the datasheet how exactly to do that. On page 31 of the datasheet, under "Bad Block Inhibit" subtitle, it is said that the chip has bad blocks which shouldn't be erased and in which data should not be stored. Also it is said that the device has a bad block inhibit function (I am not sure what exactly that is). However, it does not say that the data of the bad block cannot be read. Moving on to page 37, beneath the subtitle "Invalid Blocks", It is said that the bad block mark is in every page of the bad block. To identify a bad block, I need to read any byte from any page of a block which validness I am checking, and if the read value is 0x00 instead of 0xFF, the block is bad and I need to make an algorithm to avoid storing data into the bad block (I have not erased any bad block). When I try to read a page byte value from all the blocks sequentially (starting from block 0) to check if any of them is 0x00, the read sequence freezes at the third block. Apparently I am doing something wrong and I do not know what (note that the read and write command works for every other page except any page from block 767). How can i read a value of a bad block successfully?

I do not have a logic analyzer.

I am open to suggestions,
Best regards
 

Attachments

mckenney

Joined Nov 10, 2018
60
1) The NAND model involves
(a) reading a page from the Flash proper (Read Cell Array) into the page Buffer (Micron calls it a "Cache" and someone else a "Data Register"),
(b) writing some data bytes into the Buffer (Program Load), then
(c) re-writing the page (Program Execute).
(a)/(c) use a page address (Row) and (b) uses a byte offset (Column). You can manufacture the Row and Column addresses by extracting fields from a logical byte (in the entire NAND) address. Step (b) can involve multiple write operations (Program Load Random). Your driver will probably keep track of which page is in the Buffer (and a "dirty" bit) so it doesn't have to read or write more often than necessary.

2) The NAND devices I recall have the bad-block indicator at a particular offset in the metadata, e.g. offset 2048 in a device with 2048-byte pages. Apparently Toshiba has extended this so that every byte in a bad block reads as 0x00. This is fine for a fresh device, where every block is erased (0xFF) but seems hazardous if you've written some pages and then want to re-build the bad-block table. Maybe the answer is to read e.g. offset 2048 anyway -- since you'll never re-program that byte (no reason to), it will always show as the bad-block indicator, so there's no ambiguity.

I do think that the NAND people invented a new vocabulary for (to my mind) no real good reason.
 

Thread Starter

Nikola Ristic

Joined Aug 27, 2019
2
Hello mckenney,

Let me see if I understand you correctly. Simply put, the column address just allows me to offset the byte location within a page, and starting from that offset byte i can read/write data from/to the memory array?

In order to check for the bad block indicator, I should read the 2048th byte of any page from each block, and if it is 0x00, it should indicate that the block is bad?

Best regards
 

mckenney

Joined Nov 10, 2018
60
Yes, that's pretty much it. The "2048" comes from the 2K page size. (Some devices have e.g. 4K page size.)

Each page is really 2K + 64 bytes of "metadata", which is automatically read and written along with the data portion. You can read the bytes in the metadata, but I don't recommend writing anything there.

Needless to say, if The Book says something different, believe that.
 
Top