MSP430F5359: Clarification on "Cumulative Programming Time" for the Flash Memory

Byte / word / long word flash write will take same time on F5xx device. It is not constant time (like in F2xx family), it is different for each F5xx device (for example one F5359 can have 20% faster flash than another F5359) and because of this there is range in datasheet table.

Cumulative programming time is related to one block (128 bytes). For example, writing 128 bytes to same block (typical firmware update) is not a problem. Problem is jumping and writing bytes between different blocks, when first byte and last byte to same block are written over the cumulative programming time.

Anyway, for me best (and fastest) option is long word block write with code executed from RAM. Or double faster with smart bit enabled.

When I looked at this I concluded that it was impossible to exceed the cumulative programming time even using single byte writes.(That part gave times in terms of cycles of the Flash Timing Generator.)

Unless you write each byte more than once of course so I filed it into the non-problem folder and forgot about it.

About your first question: Yes

About your second question: Twrite = Tword ="Generate Programming Voltage" time + "Programming Operation Active" time  + "Remove Programming Voltage"

time. That is why there is difference between Block program time for first byte or word, Block program time for last byte or word and other byte or word. 

About your third and fourth questions: Are you saying that you can only program every block of MSP430 for 16ms in its lifetime?

About your fifth questions: Tlongword  is according to the mode you use. You can write it word by word or use block write mode.

> It is not constant time (like in F2xx family), it is different for each F5xx device
> (for example one F5359 can have 20% faster flash than another F5359) and
> because of this there is range in datasheet table.

And that, of course, is because MODOSC isn't a precision clock, right?

> Cumulative programming time is related to one block (128 bytes). For example,
> writing 128 bytes to same block (typical firmware update) is not a problem.
> Problem is jumping and writing bytes between different blocks, when first byte
> and last byte to same block are written over the cumulative programming time.

Oh, I see! The Family User's Guide states:

The flash memory is partitioned into main, information, and BSL memory sections.
Bytes, words, 32-byte long-words, or 128-byte blocks can be written to flash memory,
but a segment is the smallest size of the flash memory that can be erased.

So unlike most Flash memories, for Main Flash, you have a DIFFERENT Erase Block
size from the size of the Programming Block and Main Flash Segments are each comprised
of 4 128 Byte Programming Blocks!

That's a subtlety that escaped me!

An implication of all of this (including the Data Sheet Tseg_erase timing) is that erasures
can be done in parallel across multiple Erase Blocks. So when you:

• Erase an Info Flash Segment, one 128 Byte Erase Block is erased
  
  
• Erase a Main Flash Segment, four 128 Byte Erase Blocks are erased in parallel
  
  
• Do a Mass Erase, all of the 128 Byte Erase Blocks are erased in parallel
  
  
• Do a Bank Erase, all of the 128 Byte Erase Blocks in that Bank are erased in parallel

Right?

Atlant

> About your third and fourth questions: Are you saying that you can only program every block of MSP430 for 16ms in its lifetime?

No. I'm reiterating the Family User's Guide and Data Sheet's statement that once one has erased a segment, one must complete all of the reprogramming of each individual 128 byte block within that segment within 16 ms of "Cumulative Programming Time".

If you were to exceed that 16 ms, you must erase and start again.

Atlant

> When I looked at this I concluded that it was impossible to exceed the cumulative
> programming time even using single byte writes.(That part gave times in terms of
> cycles of the Flash Timing Generator.)

Yes! I had originally missed this subtlety in the Family User's Guide but it supports
your contention:

The flash memory is partitioned into main, information, and BSL memory sections.
Bytes, words, 32-byte long-words, or 128-byte blocks can be written to flash memory,
but a segment is the smallest size of the flash memory that can be erased.

Because Main Flash "Segments" (what most Flash users would call "Erase Blocks")
each contain 4 128-byte blocks, then for the MSP430F5359 and its 85 µs maximum
Tword programming time, we arrive at 10,880 µs (~11 ms) maximum to individually
program one time all of the bytes in one 128-byte block.

As you say, it appears that one need only worry about the Cumulative Programming
Time if 1) one is re-programming bytes without erasure or 2) using Block Programming
mode running from RAM but you're doing it too slowly.

Atlant

Atlant Schmidt said:

And that, of course, is because MODOSC isn't a precision clock, right?

Yes, I think this  is related to flash clock. Here you can see my test devices sorted by flashing rate (KByte/sec) value.
Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
0  91   OK   3881  1106  10   10  219CA446 1800 0F00
1  91   OK   5435  0100  10   10  ADE98146 0A00 2100
2  91   OK   3180  1104  12   12  013BB046 1200 1E00
3  91   OK   3180  1104  12   12  013BB046 0D00 1E00
4  91   OK   5435  0100  10   10  ADE98146 0400 2000
5  91   OK   3180  1104  12   12  013BB046 2A00 2100
6  91   OK   3080  1104  30   10  B15B9446 2000 1700
7  91   OK   3081  2106  10   10  B7A50951 0A00 1100

Write Test
Smart  #0    #1    #2    #3    #4    #5    #6    #7
  0    93,8 100,6 102,0 102,2 102,5 103,3 105,4 106,4
  1   216,8 232,5 235,7 236,1 236,9 238,6 243,6 245,9

Just to return to this...

Atlant Schmidt said:

I take the basic point: One can't apply high voltage stress to the flash cells in a block for more
than (in the case of my MSP430F5359) 16 ms. Doing so for longer time risks provoking errors
in any data stored in that block and possibly permanently damaging the gate oxide of the storage
transistors. So far, so good.

I was working for years on my flasher using the same F5xx target device boards, and during development this 16 ms limit was beaked many times with all kinds of other flashing failures. Flash memory on all this target devices is working (as I can see  by using marginal read) today same as when it was brand new.

> I was working for years on my flasher using the same F5xx target device boards,
> and during development this 16 ms limit was beaked many times with all kinds of
> other flashing failures. Flash memory on all this target devices is working (as I
> can see  by using marginal read) today same as when it was brand new.

That's good to know! Durable Flash is ALWAYS a good thing!;-)

Meanwhile, just for reference, here's the reply from Jens-Michael Gross in another thread
that states that exceeding Cumulative Programming Time may be harmful to the cells:

https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/19724/1476172#1476172

In block write mode, programming voltage is applied when the first byte is written to the block,
and removed from the block when either another block is written or the write mode is disabled.

The debugger halts the CPU, but does not deactivate block write mode.

It is not safe to single-step through flash write code, whether running form flash nor from ram.

if you exceed the cumulative writing time, written flash content is not reliable. Its retention time
may decrease significantly, or it may even happen that unprogrammed bits switch to '0'. Flash
will recover on next erase cycle, but applying the programming voltage for a prolonged time
will also stress the flash cell insulation as if it was programmed (and erased) many times,
reducing the number of available write cycles.

Here's what a "Long-Word" write looks like on one particular sample of the
MSP430F5359 microprocessors:

Only the beige trace labeled "DB_TP_XP" is significant.

What it's showing us is that three byte-sized writes to the Flash go very
quickly (about 1.1 µs each so probably 9 cycles of the 8 MHz MCLK) and
the fourth byte-write that completes the longword then takes 70.3 µs,
just a smidgen towards the low side of the Data Sheet's range of 64 µs
to 85 µs.

(Included in both of those times is about 1 BIS.B # & instruction's worth
of overhead as I update the DB_TP_XP GPIO signal that is being used to
demonstrate the timing of all of this; the complete code is shown below.)

This confirms that Byte Writes, Word Writes, and non-Block-Mode
Longword Writes all take the same time.

Atlant

-=-=-=-=-=-=-

Note:

Here's the actual code doing the writes shown above:

DB_TP_XP_OUT_REG |= DB_TP_XP_BIT;
    F2D080002202 BIS.B #0x80, &0x222 
*address_ptr = *Src_ptr;                  // Because we're executing from Flash Memory, whenever a longword
    FC4D0000 MOV.B @R13+, 0(R12)
DB_TP_XP_OUT_REG &= ~DB_TP_XP_BIT;        //   transfer completes, the processor will automatically JAM here
    F2C080002202 BIC.B #0x80, &0x222

Hi Atlant,

Is your question solved?

If not, can you explain to me what is the progress? I can consult our expert.

Eason