TM4C1294NCPDT: Error during interrupt based flash programming

Thanks Bob, here's more detail:

No, we are not executing from RAM when we program the flash.  From our understanding we can execute from certain sectors of flash while programming other sectors. Our application occupies less then lower about 128 kByte of RAM (0x0000 ...0x1ffff), then there is some currently unused flash, then huge area with fixed calibration data (0x80000...0xbffff) which is not changed in regular mode, and finally we have some configuration data in the upper 16kByte of flash 0xc0000 ... 0xfffff), which needs to be reprogrammed from time to time. We believe(!) that we have done  some protection in out firmware, that we are not trying to access the configuration data while we are reprogramming this sector. Actually we set a “busy”-flag before we start to erase this upper sector and clear this flag after programming the last page of this upper flash sector. And we believe that we query this busy flag before we access the configuration data. We have crashes due to programming attempts to the flash only occasionally. I’m 99% certain, that either an interrupt tries to access the configuration data without querying this busy flag or the external control software tries to reprogram this configuration data before the previous programming cycle is really finished. It very much looks like OUR firmware problem. But, we have not seen any sample program nor does the TIVAWARE  flash programming with using the interrupt feature as we do  (certain functionality must be available while erasing and reprogramming the configuration data and therefore we don’t want to wait in a polling loop as the TIVAWARE does). That’s why we asked if there is a known problem with flash erasing and programming in interrupt mode.

FRAMziskus said:

 From our understanding we can execute from certain sectors of flash while programming other sectors

That is not correct. The information I quoted above if from page 545 of the datasheet:

If you require functionality during the flash programming, that code must be executed from RAM.

Can the configuration data fit in the emulated EEPROM instead?

Team,

I am sorry, but I have entered the wrong part number for this thread!
The part number my customer is using is: TM4C1294NCPDT
Page 612 states:

Sorry for the confusion!

(Can you adjust the thread title?)

Or external Non-volatile memory. Choice depends on how many units you sell, how often the updates are, how large the required storage, what conditions under which updates happen and the consequences of corruption.

The on-board EE does require care. Read the Errata (you should do that for the flash as well). The care required is rather less burdensome than that for the flash though.

Writing to flash imposes a large burden

• Writing time. You have to consider the max time to erase and program in your calculations
• Reduced available memory. Given the memory on these devices that may not be a burden.
• lack of access to memory while you write. You indicate writing to one bank doesn't affect the other but are you sure you've identified the banks correctly? On many micros the banks are interleaved, I don't know about this one.
• The extra programming effort to manage it. This is already causing problems. A question to consider: How many extra units do you have to sell to make up for the extra programming time involved to save an external non-volatile memory or worse on-board EE?

Robert

May we wonder just "how" any, "design in trouble - at minimum in high flux/uncertainty" can be categorized as, "too advanced?"

A "far safer path" would see the creation of a, "Second, Parallel Design" (external memory) - developed in conjunction w/the "under-estimated" - thus far - "flawed" - initial design approach.

Having "more than one Safe return Port" - while "at sea" - w/dark clouds rising - proves extremely smart - at times life (or career) saving!   

FRAMziskus said:

Do you see any issue with interrupt-based flash erases and writes vs polling-based?

First of all application does not need to first erase the address written to if only a few hundred bytes are being changed. Others above posts divert how topic of where to store said data as flash writes only guarantee million or so R/W cycles before memory cell begins to degrade. That doesn't stop application engineers who often store small parameter block to flash. Yet RAM becomes choice for very large and frequent parameter block changes pushed up to EEROM for safe keeping. EEROM too has limited R/W cycles before memory cell degradation (entropy) the enemy of both flash & EEROM.