F021 (65nm) flash memory - write/erase cycles

Jiri Janacek

Genius 3315 points

Other Parts Discussed in Thread: TMS570LS3137

Dear all,

the TMS570L3137 datasheet spns162a states on the page 75 as follows:

program flash | 1,000 w/e cycles

data flas | 100,000 w/e cycles

I am a bit surprised of different values for the bank 0/1 and bank 7 (EEPROM emulation).. Memory technology is the same one (F021) in the both cases so I would assume also the same life cycle / retention, would not?

Although one Byte is written into the babk 7 by a user application, the flash wrapper must erase a whole appropriate sector and then write in just the Byte, does not?

Thanks for clarification in advance,

Cheers, Jiri

over 11 years ago

0 Chuck Davenport over 11 years ago

TI__Guru 59540 points

Hello Jiri,

There are other dependencies for the cycle limitation other than just the sectors. The flash is divided down from the full bank to blocks then to sectors. For the program flash there are multiple sectors within individual blocks and the cycling will impact all sectors within that block. In other words, if you have 2 16kB sectors within a single block and one of these sectors contains a boot code such that you are operating from that sector while programming the other. The cycles on the sector being programmed will impact the first sector that is only being read.

For the data flash, we specifically design the blocks so that there is only one sector within each block. This approach is less efficient in some ways but allows for the higher cycle count.

0 Jiri Janacek over 11 years ago in reply to Chuck Davenport

Genius 3315 points

Hello Chuck,

please let me try to simply link your description with terminology of F021 memory within the TMS570LS3137 device.

The cycles on the sector being programmed will impact the first sector that is only being read.

>>>

Within the F021 memory, if bank 0 is being programmed, programming code must run from bank 1 (or RAM, of course) and vice versa. Then is cycle limitation of the bank 1 really affected by that?

The flash is divided down from the full bank to blocks then to sectors.

>>>

AFAIK within the F021 memory the bank is split into sectors. Maybe it does depend on a point of view - user can recognize bank and sectors named block in your terminology. The actual internal implementation could be as follows:

Bank 0 - sector/block 0 (32KB) - two "physical" sectors (2 x 16KB)

Bank 1 - sector/block 0 (128KB) - eight "physical" sectors (8 x 16KB)

Bank 7 - sector/block 0 (16KB) - one "physical" sector (1 x 16KB)

Is this absolutely crazy or close to the reality? ;-)

Thanks a lot,

cheers, Jiri

0 Chuck Davenport over 11 years ago in reply to Jiri Janacek

TI__Guru 59540 points

Hello Jiri,

Let me explain a bit differently. For flash defined as normal program space there are multiple banks. Each of these banks is divided into blocks and each of these blocks are devided into sectors. The blocks are a design element that increase the efficiency of the flash in regard to space on the die but really have no impact on performance in regard to reads. However, each time a sector is erased, it impacts all sectors within that block from a write/erase cycling perspective.

Since program flash is generally very large compared to the EEPROM emulation flash, we combine sectors within blocks to improve the die size allowing for a more cost effective design with the down side that they are not proficient for w/e cycles and, therefore, limited to only 1000 w/e cycles.

For the example I mentioned regarding a boot sector, where you are executing from one sector and programming a second, this was hypothetical without respect to limitations on programming the same bank from which you were executing. The intent was to simply describe that both sectors within the block are impacted by the erase.

For the EEPROM emulation bank, we explicitly design them so that each block contains only 1 sector so we can maximize the write erase cycles to 100k cycles.

If we explicitly look at bank 0 sectors 0 - 6 for the LS3137 device you mention above, they are configured as shown below:

Bank 0 - Block 0 (256kB) - 5 physical Sectors (4x32kB, 1x128kB)

Bank 0 - Block 1 (256kB) - 2 physical sectors (2x128kB)

and so on down the list of sectors until the total 1.5MB of bank 0 is accounted for.

Since the blocks are transparent to the user (no block erase or wrie feature) we don't include this level of detail in the datasheet.

Hopefully this makes it a bit more clear. The bottom line is there is an underlying flash bank architecural element affecting the w/e cycling specifications for program storage space vs. EEPROM emulation storage space.

0 Jiri Janacek over 11 years ago in reply to Chuck Davenport

Genius 3315 points

Hello Chuck,

thanks for your description in detail!

Well, if we consider simple (rather silly) write/erase cycle upon just one Byte (sector respectively), we would get the same low endurance (1000 cycles) for Bank 0/1 and Bank 7., would not we?

But we should consider a different approach to the program and the data memory - usually we avoid any change and movement of some program borders. On the other side, when writing small data table, we can write newer table version behind the end of the previous one and erase the whole sector after reaching the sector border.

Well, but in such a case I would assume a requirement in the datasheet to apply similar approach to "increase" EEPROM-flash endurance.

Of course, I can imagine a situation when data set shall lie on the same addresses for the whole life cycle.

I think that I am still overseeing some important fact ;-)

Thanks in advance,

cheers, Jiri

0 Chuck Davenport over 11 years ago in reply to Jiri Janacek

TI__Guru 59540 points

Hello Jiri,

Certainly, if you only programmed one byte at a specific address and always erased the whole sector each time you re-programmed the byte, then it would be a similar concept. The difference is in the program banks (0 and 1) we have multiple sectors within a block and any time an individual sector is erased it degrades the w/e cycles of the all the sectors within that block. If we had byte write/erase capability within the sectors and each cycle on the byte impacted the entire sector, this would be a similar concept.

To add to the complexity, there is no block erase function so we have to initiate several sector erase commands within each block. So for the first block I mentioned in the earlier post, there are 5 physical sectors and to erase the entire block, there would be 5 sector erase tasks which would "burn" 5 cycles for each sector with only 4 of them being intended erase cycles.

In bank7 we have only one sector in each block so there is only one cycling hit each time the sector is erased allowing for more accountability in the cycles.

In the end, the position is that 1000 cycles for program memory should be more than adequate for almost all application uses. For data that needs to be constantly updated there is the data bank, ban7, which has the 100k cycle capability.

Out of curiousity, is there a need for your application to have more than 1000 cycles for bank0/bank1?

0 Jiri Janacek over 11 years ago in reply to Chuck Davenport

Genius 3315 points

Hello Chuck,

thanks for your detailed information!

Of course, 1000 cycles are pretty enough for the production deployment of an application.

Anyway, this boundary can be reached during development phase if I do not intend to run program code from RAM.

Best regards,

Jiri

0 Chuck Davenport over 11 years ago in reply to Jiri Janacek

TI__Guru 59540 points

Hello Jiri,

Thanks for wrapping the discussion up. I would agree that this boundary could be reached during development but also keep in mind that this boundary is across temperature, voltage and process ranges for the device so it is unlikely that this would cause any problems in a development environment. To date, I have not seen this become an issue for a customer.

Arm-based microcontrollers

Arm-based microcontrollers forum

F021 (65nm) flash memory - write/erase cycles