Nand Flash Q&A

Nand Flash is a lot different from Nor Flash, and there will be error bits randomly occurring on Nand flash devices and further causing bad blocks. This is the nature of Nand flash device, and that's why bad block management(BBM) is important on universal programmers or Nand programmers.

LEAP Universal Programmers offer complete bad block management functions and settings for users to customize the partition and set the allowed bad block numbers in each partition.

SU-600 Universal Programmer For Nand Flash, Nor Flash, MCUs.

SU-6000 Universal Gang Programmer For Nand Flash, Nor Flash, MCUs.

SU-320 4-Site Universal Programmer For Nand Flash, Nor Flash, MCUs.

SU-3280 16-Site Universal Programmer For Nand Flash, Nor Flash, MCUs.

Q&A

Q1.

What is the Bad Block checking method of LEAP universal programmers?

Will Bad Blocks be marked when programming?

A1.

Bad block marking rules vary from different IC makers, and below are some of

the common Bad Block verifying methods:

a. The 1st Byte of the Spare area in the 1st or 2nd Page of each block is not 0xFF.

b. The 1st Byte of the Spare area in the first or last Page of each block is not 0xFF.

c. The 6th Byte of the Spare area in the first or last Page of each block is not 0xFF.

LEAP Programmers will run the bad block verifying procedures according to the

IC Datasheet of each part number. During our ERASE procedures, the bad block

markings made by IC makers will be kept and then remarked after ERASE procedures.

During programming, our programmers will program each block in sequence

according to the Group Define settings or file.

Blocks already marked as Bad Block will be skipped to the next good one.

Blocks will be marked as Bad Blocks when programming fails on these blocks and skipped.

Q2.

How do we deal with Bad Blocks when calculating Checksum and Verifying files?

A2.

Bad Blocks are omitted when reading out NAND FLASH data as a default setting.

Checksum is calculated by the total value of all data including Spare area,

but due to error bit issues on NAND Flash, verifying by Checksum is not recommended.

It is recommended to verify with loading Group Define files and follow the same programming procedures, dealing with each block in sequence. Blocks marked as bad block should be skipped to the next good one and if there's data error in a good block, the total error bit amount in each page will then be calculated. If the total error bits get over those of the allowed standard set by IC makers, verify process will fail.

Q3.

Can our programmers detect Bit Errors?

A3.

During programming, universal programmers will send commands and Page data to the internal controller of NAND

FLASH devices and read out Status Register to check if the Page programming on the device is finished and

if the programming result of that page is Pass or Fail.

Verifying procedures will first check if the Page data and Source data are exaclty the same, and if not, bit

verifying will proceed to check if the error bits get over the standard set by IC makers.

Q4.

Can programmers generate ECC algorithm?

A4.

With the growing popularity of MLC and TCL NAND Flash, ECC algorithm has been getting a lot more

complicated in all forms. Different ECC algorithms will be used for different Nand Flash devices according to

their production procedures. Normally ECC algorithms will be made by IC makers and be saved in files to be

written in when programming.