LPC1769 Chip_IAP_CopyRamToFlash() flips flash bit from 0 to 1

[lpcware]

Content originally posted in LPCWare by gbiagioni on Thu Jan 07 18:20:40 MST 2016
Below is the 'write to flash' routine I want to use in a Flash Translation Layer for the high half of on-chip flash memory.

Below that is a sample result that shows Chip_IAP_CopyRamToFlash() flipping a bit from 0 to 1, something I thought not possible. Is there a problem with the chip, or can this really happen? My whole FTL strategy relies on being able to
re-write 512 byte blocks as long as I only attempt to change 1's to 0's. I've done this successfully with off-chip flash, and
am very surprised at what I am seeing here.


1   bool  FlashStorage::writeFlashBlock(const void * src, void * dst)
    {
2    uint32_t    sector = sectorNumber(dst);
3    bool        result;

4    __asm volatile ( " cpsid i \n" );   // disable interrupts

5    result = Chip_IAP_PreSectorForReadWrite(sector, sector) == IAP_CMD_SUCCESS
            && Chip_IAP_CopyRamToFlash((uint32_t)dst, (uint32_t *)src, FLASH_BLOCK_SIZE) == IAP_CMD_SUCCESS;

6   __asm volatile ( " cpsie i \n" );   // enable interrupts

7    return result;
     }

line 4 - memory at src (in  RAM)

0x10002EA4  00000000 FFFFFF00 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0x10002EC4  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0x10002EE4  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

line 4 - memory at dst (in Flash)

0x00040000  00000000 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0x00040020  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0x00040040  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

line 7 - memory at dst

0x00040000  00000400 FFFFFF00 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0x00040020  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0x00040040  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

'result' is 'true' at line 7

[lpcware]

Content originally posted in LPCWare by vtw.433e on Fri Jan 08 02:00:35 MST 2016
No. It is the nature of the Flash. Virtually all MCU's use this type of on-chip flash. If you want to 'erase' smaller sectors you have to simulate it yourself by copying the original contents, erase, merge with your new data and copy back to flash. Of course, you then have to be careful with number of erase cycles (order 100k on these devices - but check the datasheet)

[lpcware]

Content originally posted in LPCWare by gbiagioni on Thu Jan 07 19:51:06 MST 2016
Oh - is there an undocumented interface that allows me to erase the smaller (256 byte) pages.

[lpcware]

Content originally posted in LPCWare by gbiagioni on Thu Jan 07 18:59:35 MST 2016
Ouch

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Thu Jan 07 18:33:10 MST 2016
The flash embedded in the NXP devices (17xx family at least) is not the same
as more conventional NOR flash used in external flash chips.

Incremental programming is NOT possible.

Each unit (probably a 256 byte page but this will be implementation dependant)
is erased and re-written as a whole.

Hence the apparent 0 to 1 anomaly that you are seeing.

NB: The documented interface only allows for full sectors to be erased.

This threw me too at first.

Cheers, Mike.