Flash Write Problem

Most likely, there is a problem in some of the Flash memory cells.

To rule out possible improper handling by CCS, I suggest that you use FET-Pro to write all 0x00 bytes to those segments of Flash and check if FET-Pro can do it.

By the way, can you use “marginal read modes” to check the Flash? I wrote my own program in assembly under KickStart to check Flash erase/write operations with both marginal read modes. (Did not find any bit marginal so far.)

Can you use KickStart?

Barry Webb said:

Is there anything I could have done in software that could have caused this?

Surprisingly, yes. But not easily.

The flash controller does not check the number of write operations and the the time thy cause the programming voltage applied to a block of flash cells. But there is a maximum programming time that must not be exceeded. If you do, it may happen that some cells are programmed which weren't intended to. Data retention time drps and the whole flash block ages prematurely. Most of these effects are reversed when you erase the block, but not completely.

On older MSPs, you had to provide the flash clock for the controller, and you were able to write a flash block byte b byte. In the published demo this was done. Unfortunately wven with the highest allowed flash clock, this algorithm was exceeding the maximum programming time, let alone with a slower flash clock.

So yes, if your flashing function violates the maximum programming time, it could damage flash cells, while you won't notice it at first and all seems to look well.

The beforementioned marginal read modes (on newer MSPs) will reveal if a cell is weak. This would not only show damaged cells but maybe problems with the flash writing algorithm (but then, these MSPs handle flash clock and timing automatically and do not perform single-byte writes, so unless you program the same byte over and over again, it's difficult to do something wrong). But I'd gues sthat the programming algorithm used by the FET is correct, and since you're seeing your problems when flashing from CCS too, it cannot be the writing algorithm that fails now, but it's most likely the flash cell that is indeed damaged.

You can try reviving the chips by performing a bunch of erase operations in a row. Liek with old NCd batteries, it might bring the cell back to life. Not to virgin state, but better than now.

Jens-Michael Gross said:

On older MSPs, you had to provide the flash clock for the controller, and you were able to write a flash block byte b byte. In the published demo this was done. Unfortunately wven with the highest allowed flash clock, this algorithm was exceeding the maximum programming time, let alone with a slower flash clock.

By "older MSPs", do you mean the 1xxx series?  Because my calculations for a few 2xxx parts show that they are inherently OK.  I just want to make sure that I'm doing my calculations right so I don't cause a problem of my own in a bootloader I'm working on.

For some sample 2xxx parts, the 23x / 24x(1) / 2410, and the 20xx, I see that tCPT (cumulative program time) is 10ms for both parts.  The time to write a byte is 30 tFTG periods, of which 27tFTG are spent with voltage applied.

So with the fastest flash clock of 476kHz:

Cumulative program time = (64 * 27) / 476kHz = 3.6ms

At a slow clock of 257kHz:

Cumulative program time = (64 * 27) / 257kHz = 6.7ms

Even if the full 30 tFTG periods are required, we're still under 10ms.

 

If I go back to the datasheet for the 15x / 16x / 161x, I see tCPT is 4ms, and it takes 32 tFTG periods to perform a byte write.

So at the fastest 476kHz clock:

Cumulative program time = (64 * 32) / 476kHz = 4.3ms > 4.0ms!

So is this the example of where the cumulative programming time can kill a chip when writing byte by byte?

Michael Bendzick said:

By "older MSPs", do you mean the 1xxx series?

Not specifically. The flash controller itself is the same for 1x and 2x family.
I just checked teh MSP430F20xx datasheet, and here, the cumulative programming time for a 64 byte bock is 10ms.

The required clock cylces for programming 64 individual bytes is 1920 clock cycles, resulting in a minimum frequency of 192kHz. Which is below the already required minimum frequency of 257kHz.

But on the 1232, the maximum cumulative programming time is 4ms and 2240 cycles are needed, which results in a required minimum frequency of 560kHz for 64 byte writes and is above the allowed maximum frequency of 476kHz.

I'm not sure whether the values are different for different members of the families. This is possible since both, frequencies and programming clock cycles and maximum times are specified in the device datasheet, not in the users guide.

Michael Bendzick said:

for the 15x / 16x / 161x, I see tCPT is 4ms, and it takes 32 tFTG periods

35 in my datasheets for the 1232 and 1611.

I think the example code was written for the 1x family. Of course the increase of the maximum write time to 10ms has relaxed things. Maybe it' sjust a datasheet change, maybe flash has been improved. I don't know. Maybe it's still safe for the 1x devices too.

Michael Bendzick said:

So is this the example of where the cumulative programming time can kill a chip when writing byte by byte?

Not kill. Only that the cells may hold invalid values until next erase. And maybe the maximum number of write cycles is reduced a bit (extended wear). But a segment erase will turn the cells back into operational state.

Michael Bendzick said:

Even if the full 30 tFTG periods are required, we're still under 10ms.

IMHO, it's not a max value. It takes 30 (35) cycles. Always. Maybe not if you write 0xff to a location, then maybe 0 cycles are required :)