1/10 march 2001 AN1122 application note applying protection and unprotection to m29 series flash memories contents n introduction n history of block protection n which blocks should be protected? n techniques for controlling block protection C programmer techniques C in-system techniques C temporary unprotection C notes on the reset/block temporary unprotect pin and v id n the three operations involved in protecting and unprotecting blocks n block addresses in the flowcharts n conclusions n revision history n flowcharts C programming equipment protection flowchart C programming equipment unprotection flowchart C in-system protection flowchart C in-system unprotection flowchart introduction this application note describes the techniques used to protect and unprotect the blocks in m29 series flash memories. the application note applies to the revision a, revision b and re- vision d m29 series flash memories, where the details of the protect and unprotect operations are not presented in the datasheet. the first version of the memories, with no revision letter, use algorithms presented in their respective datasheets. when a block is protected the flashs program/erase control- ler will not allow changes to the block. it will not be possible, us- ing any unwanted electrical signals or software commands, to change the data, either by accident or on purpose. this gives added confidence that, if the flash is used for code storage then the product will always be able run after a reset, even if the software has erroneously tried to reprogram the flash. history of block protection in the early days of flash the security of data was a major con- cern. designers used to using eproms and roms were very concerned that the contents of flash could become corrupt. the design of roms and eprom does not allow them to be- come corrupt once in the system. to overcome this flash man- ufacturers used several techniques to protect the flash. the coded cycles required to execute the program or erase opera- tions make it almost impossible for random write sequences (either from erroneous software or power-up/power-down elec- trical noise) to damage the contents of the flash. all flash memories have a lockout voltage, v lko , to increase data se- curity during power-up/power-down. for those who remained unconvinced about the security of flash, block protection was also provided. recently designers have tended to rely on the coded cycles and lockout voltage to protect the flash. leaving the blocks unprotected has allowed greater flexibility because application code can be updated in-system without removing the flash from the board. the security provided by the coded cycles and lockout voltage is rarely, if ever, breached, and the advantage of allowing in-system upgrades can be a greater benefit than the risk of losing or corrupting the code.
AN1122 - application note 2/10 which blocks should be protected? if a designer is not happy with the protection provided by the coded cycles and the lockout voltage then a decision has to be made as to which blocks need to be protected and which ones do not need protection. a simple way to design the system is to use a small boot program that runs and performs a system check before the main application runs. the boot program is clearly very important because, without it, nothing will run. the boot program can also alert the user to an error in running the application by giving an indi- cation that is more positive than merely not executing at all. by incorporating a download feature into the boot code the application code can be updated in-system. (a download feature is one that allows the application code to be changed by the microprocessor.) fur- thermore, if something goes wrong while the application code is downloading, the system will still boot and it will remain possible to attempt another download of the application. if any blocks are going to be protected, the one with the boot code should be the first choice. this allows systems that have become corrupt to inform the user of the problem. the system can be fixed without the flash being removed from the circuit board (not easy since most flash is surface mount). the designer may still not be happy with the protection provided for the application code. if the designer chooses to protect the application code then field updates are not really feasible. depending on the flash it may be necessary to remove the flash from the circuit board to perform application upgrades. however, there are products where the code is fixed and no field upgrades are ever expected (e.g. hard disk drives). flash may be a preferred choice over eprom for these applications because it allows other blocks to store data, a facility that eproms cannot provide. stmicroelectronics does not recommend protecting blocks that have data in them, unless the data is only updated as often as the application code. the number of times that protection can be applied and removed is not guaranteed. once a design is able to remove protection without external intervention then it is no longer any more secure than a design that does not use protection at all. the main mode of failure for unprotected blocks is through software failure and, once software has control of the unprotect operation, it can corrupt the application code as easily as changing the data. techniques for controlling block protection unlike the command interface of the program/erase controller, the technique for protecting and unpro- tecting blocks changes between different flash memory suppliers. for example, following the techniques for amd parts will not work on stmicroelectronics parts. care should be taken when changing drivers for one part to work on another. there are three techniques for controlling whether a block is protected or not. not all techniques are avail- able on all types of flash memory. the techniques available are: 1. programmer technique (using special bus operations, not available on a standard microprocessor bus). 2. in-system technique (for flash memories already surface mounted onto the circuit board). 3. temporary unprotection (again, for in-system flash memories). technique 1 (programmer technique) is available on all types of flash memory. technique 2 (in-system technique) is available on b and d revision memories with a reset/block temporary unprotect pin; these include memories such as the m29f400b, m29w400b, m29f160b, etc. technique 3 (temporary unprotection) is available on all flash memories with a reset/block temporary unprotect pin. note that the revision letter appears after the part number, but this can be confused with the array matrix selection for bottom boot block devices. for example the m29f400b device is an old revision memory, the new revision is m29f400bb. the family name is m29f400 for the old family and m29f400b for the new family. take care when deciding which part and revision is being used. if in doubt use the full part name and refer to the correct version of the data sheet.
3/10 AN1122 - application note not all flash memories allow the protection of each block to be set individually. devices such as the m29f080a, m29f016b, m29f080d, m29f016d and m29f032d require the blocks to be protected in groups. on these flash memories it is only necessary to follow the protection flowchart for one of the blocks in the group and all of the blocks in the group will become protected. the protection groups for these parts are listed in the block addresses table of their data sheets. programmer technique programmer equipment manufacturers should follow figure 1, programmer equipment protection flow- chart, to protect blocks in the flash. figure 2, programmer equipment unprotection flowchart, should be used to unprotect all blocks at once. due to the internal design it is necessary to protect all blocks before starting the unprotect operation. furthermore, all blocks must be unprotected at once. it is not possible to unprotect a single block in the same way as it is not possible to erase a single byte in the flash memory array. the flowcharts should be followed exactly and should not be aborted before reaching the end. the un- protect operation can take several seconds, so it might be useful to inform the users that the operation is progressing, otherwise they may believe that nothing is happening. in-system technique once the flash has been fitted onto the circuit board the in-system technique for contro lling protection should be used. this has been included in the new flash memories because it is difficult to remove sur- face mount parts; a five minute update task can take several days while the part is sent away for removal, returned, updated and then sent away again for fitting. as already described, the in-system technique is only available on b and d revision flash memories which have a reset/block temporary unprotect pin. to use the in-system technique follow the flowchart in figure 3, in-system protection flowchart, to pro- tect blocks in the flash. use the flowchart in figure 4, in-system unprotection flowchart, to unprotect all the blocks at once. again, it is necessary to protect every block before unprotecting all the blocks. the flowcharts should be followed exactly and not aborted before reaching the end. the unprotect oper- ation can take several seconds, so it might be useful to inform the users that the operation is progressing, otherwise they may believe that nothing is happening. temporary unprotection flash memories that have a reset/block temporary unprotect, rp , pin can have the best of all worlds. blocks can be protected during the manufacture of the product after the code is programmed into the flash. then, if the product is returned later for upgrade, the reset/block temporary unprotect pin can be raised to v id , temporarily cancelling the protection on the protected blocks. when the reset/block tem- porary unprotect pin drops outside the v id region the blocks that were previously protected become pro- tected again. notes on the reset/temporary unprotect pin and v id by putting the source of v id external to the product and not within the control of the microprocessor it will be impossible for the flash to become corrupt during normal operation. the reset/block temporary un- protect pin can be put on a header on the board to allow for simple connection during upgrades. it is im- portant to include circuitry that will prevent the reset line to other parts in the system being dragged to v id and also prevent the reset/block temporary unprotect pin from making the transition from v ih to v id fast- er than v phphh . if field updates are required then a jumper could be used to raise the reset/block tem- porary unprotect pin to v id , the system is still secure because the microprocessor cannot put the jumper on itself.
AN1122 - application note 4/10 the three operations involved in protecting and unprotecting blocks the bits that hold the protection status of a block are standard flash memory cells. they can be pro- grammed individually (to protect the block) and erased in bulk to unprotect all blocks. unlike the cells in the memory array, the program/erase controller does not take care of the specific signals required to pro- gram and erase the protection cells. these have to be performed carefully by following the protection and unprotection flowcharts. there are three distinct operations that involve the protection bits in a flash memory. these are: 1. reading the protection status of a block 2. programming a protection bit of a block 3. verifying a protection bit of a block the protection bits are read as normal flash memory cells, the output of the cell is fed to a sensing am- plifier that decodes the value stored in the cell to a 1 or a 0. the protection bits can be read using the autoselect command, they are also output as part of the protection verify operation. programming a protection bit involves removing charge from the floating gate of the flash cell. charge is removed a bit at a time to avoid removing too much charge; removing too much charge from the floating gate can damage the cell. each time the protect part of the flowcharts is performed more charge is re- moved from the floating gate. the verify stage of protecting a bit reads the block protection status while applying a bias to the sense amplifier. this ensures the cell is programmed strongly enough to always read correctly under any condi- tion (for example when very hot or very cold). when protecting it is very important to ensure that the cell outputs the protected state using the verify command, otherwise the cell may output the wrong value under other conditions, allowing program and erase operation to change the contents of a cell that the user thought was protected. the same three stages exist when unprotecting a block too. when unprotecting however, the unprotect operation works on all cells at once, whereas the unprotection verify operation needs to check each pro- tection bit individually. during the unprotect verify, the opposite bias is applied to the sense amplifier to ensure that the cell is erased strongly enough to always read correctly under any condition. it is vital that the unprotection verify is carried out on all blocks and that none are missed. it is not recommended that the user read the status of the protection bits (operation 1. above) in order know if the sector is protected or not since there is no margin in this operation. the best method is using the unprotect verify and protect verify bits. if the user does however read the status of the protection bits (eg. in auto select) then a way to improve margin is to read over all ranges of operation of the device for example at both 4.5v and 5.5v for a 5v device (2.7v and 3.6v for a 3v device). block addresses in the flowcharts to protect and unprotect the blocks the addresses need to be specified correctly for the block(s) of inter- est. when protecting the flash, many of the address pins do not need to be specified (they are dont care), however some do need to be correct. in all flash memory devices a0, a1, a6 need to be correct during block protection, as well as the bits that specify the block address. in addition to these, when using the programmer technique a12 and a15 need to be correct during blocks unprotection (the m29f080a and m29w008a parts are special and re- quire a12, a13, a15 and a16 to be correct). the flowcharts specify the values that these addresses should take. when a block address is required in the flowchart any address in the block that keeps a0, a1, and a6 correct may be chosen. a simple way to choose the address is to choose the first address in the block from the block addresses table of the data sheet and or it with the values of a0, a1 and a6, leav- ing the other bits at 0.
5/10 AN1122 - application note when using flash memories with a byte pin take care that the addresses are specified in the flash mem- ory address space, not the address space of the microprocessor. usually a1 of the microprocessor ends up connected to a0 of the flash, so the addresses must be shifted accordingly. conclusions block protection can be a useful feature for people who require utmost security for the contents of the memory. usually only the block containing the boot code will be protected. flash memories from stmicroelectronics provide several techniques for the user to choose between for controlling the protection of blocks. programmer equipment manufacturers can use the techniques that are compatible with old parts, product manufacturers can use in-system techniques to change the block protection after the flash has been put on the circuit board. temporary unprotection can be used to up- date application code without compromising the strictest of security specifications. whatever your block protection requirements, stmicroelectronics flash memories have a suitable solu- tion for you. revision history date version revision details april 1999 -01 first issue august 1999 -02 in-system protection figures revised: added additional write 60h box at the top of the flowchart. this is required by the internal algorithms. november 1999 -03 clearer specification of when the three techniques can be used. modified to account for a12, a13, a15 and a16 being required at v ih during the programmer technique blocks unprotection. june 2000 -04 added the section on the three operations involved in protecting and unprotecting blocks. added a paragraph warning about the differences between the protect/ unprotect operations in amd and stmicroelectronics flash memories. added notes to the in-system unprotection flowchart. march 2001 -05 added extra paragraph in the three operations... section to clarify that the sector protection status bit has no margin. added references to m29 d version
AN1122 - application note 6/10 figure 1. programmer equipment protection flowchart address = block address ai02989 g, a9 = v id , e = v il n = 0 wait 4s wait 100s w = v il w = v ih e, g = v ih , a0, a6 = v il , a1 = v ih a9 = v ih e, g = v ih ++n = 25 start fail pass yes no data = 01h yes no w = v ih e = v il wait 4s g = v il wait 60ns read data verify protect set-up end a9 = v ih e, g = v ih
7/10 AN1122 - application note figure 2. programmer equipment unprotection flowchart note: 1. for the m29f080a and the m29w008a set a6, a12, a13, a15 and a16 to v ih . protect all blocks ai02988 a6, a12, a15 = v ih (1) e, g, a9 = v id data w = v ih e, g = v ih address = current block address a0 = v il , a1, a6 = v ih wait 10ms = 00h increment current block n = 0 current block = 0 wait 4s w = v il ++n = 1000 start yes yes no no last block yes no e = v il wait 4s g = v il wait 60ns read data fail pass verify unprotect set-up end a9 = v ih e, g = v ih a9 = v ih e, g = v ih
AN1122 - application note 8/10 figure 3. in-system protection flowchart ai02987b write 60h address = block address a0 = v il , a1 = v ih , a6 = v il n = 0 wait 100s write 40h address = block address a0 = v il , a1 = v ih , a6 = v il rp = v ih ++n = 25 start fail pass yes no data = 01h yes no rp = v ih wait 4s verify protect set-up end read data address = block address a0 = v il , a1 = v ih , a6 = v il rp = v id issue read/reset command issue read/reset command write 60h address = block address a0 = v il , a1 = v ih , a6 = v il
9/10 AN1122 - application note figure 4. in-system unprotection flowchart ai02986b write 60h any address with a0 = v il , a1 = v ih , a6 = v ih n = 0 current block = 0 wait 10ms write 40h address = current block address a0 = v il , a1 = v ih , a6 = v ih rp = v ih ++n = 1000 start fail pass yes no data = 00h yes no rp = v ih wait 4s read data address = current block address a0 = v il , a1 = v ih , a6 = v ih rp = v id issue read/reset command issue read/reset command protect all blocks increment current block last block yes no write 60h any address with a0 = v il , a1 = v ih , a6 = v ih verify unprotect set-up end notes: 1. during the unprotect operation (in- cluding the wait) it is essential to keep w high. the memory is en- abled internally and any write cy- cle on the bus may upset the un- protect operation. 2. in order to read the unprotection verify status of each block correct- ly, e, must remain low for the write 40h command, throughout the wait, until the data is read. the values of a0, a1 and a6 must also remain constant throughout this period.
AN1122 - application note 10/10 if you have any questions or suggestion concerning the matters raised in this document please send them to the following electronic mail address: ask.memory@st.com (for general enquiries) please remember to include your name, company, location, telephone number and fax number. information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without express written approval of stmicroelectro nics. the st logo is registered trademark of stmicroelectronics all other names are the property of their respective owners. ? 2001 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - brazil - china - finland - france - germany - hong kong - india - italy - japan - malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - u.s.a. www.st.com
|
