Working with the K20 tower and CodeWarrior, and my FlexNMW is coming up already partitioned. I get 3 for EESIZE and 0xB for DEPART

I'm working with the TWR-K20D72M, Code Warrior 10.4, PE, and Multilink Universal. After downloading my code, if I have the debugger stop at code entry, I see the value of 0XFF030B00 in SIM_FCFG1. I have tried using the "Enable Partitioning for the device" selection in "Advanced Programming" under "Debug Configurations", and some settings work while others don't. I can't configure the FlexNVM to a "No EEProm" state. I'm assuming I need the chip in this state to test any application code that will partition the memory when the chip is first configured.

I contacted Roger Collins to find out what his solution was, and he said he never found one.

What I ended up doing was configuring the EEPROM space through Debug Configurations->Connection:Edit->Connection:Advanced Programming Options->Enable Partitioning for the device. I used 0x3601 which sets the device up for 256 bytes EEPROM space and 24K NVM. I did this and downloaded once, then unchecked "Enable Partitioning for the device". This seems to have programmed the partition, and leaves it alone for the rest of development. I then checked the non-volatile perfomance of the data by setting values in the EEPROM, power cycling, and outputing them from my device to verify that they were there. They were. It seems that one cannot work with the debugger and non-volatile memory. Every time I download, the non-volatile memory gets erased. Even when I try to tell the debugger to preserve portions of the memory (when I do that, I get an error, and am unable to continue). I never got the device to show the unprogrammed state. We will have to see with a new board...

e6272: SIM: The System Integration Module Registers may not be programmed correctly.

Errata type: Errata

Description: The following System Integration Modules Registers may not be programmed correctly: the FAMID and PINID bit fields in the SIM_SDID Register, the RAMSIZE in the SIM_SOPT1 Register, the NVMSIZE, PFSIZE and EESIZE in SIM_FCFG1 Register and information in the Unique ID Registers SIM_UIDx.

Workaround: In next revision of silicon, these values will be programmed correctly.

I can use on board OSJTAG tool to mass erase the chip and can get the chip Data Flash IFR address 0xFC and 0xFD with 0xFF value.

Then it can run the Program Partition Command after Erase ALL Blocks Command.

You could check below picture to get more detailed info:

I would recommend customer to use Read Resource Command to get Data Flash IFR value instead of using SIM_FCFG1 register.

Thank you Hui_Ma. I have downloaded the C90TFS package and will start looking it over. I was using code found in CW_MCU_v10_1_Examples that executes if ((SIM_FCFG1 & SIM_FCFG1_DEPART(0xF)) != 0x00000F00). I take it this is no longer recommended? Also, I wrote code that performed a mass erase, and set a break point afterward (from RAM). I read the correct values from SIM_FCFG1, but of course any code in flash had been erased. When I downloaded again, the value in SIM_FCFG1 had changed. When you say "Then it can run the Program Partition Command after Erase ALL Blocks Command." do you mean you have a way of getting program code into flash after the erase without changing the values in SIM_FCFG1?

For there with SIM_FCFG1 errata issue, there is no recommend to detect SIM_FCFG1 register value checking before do program partition command. I would recommend customer to use Read Resource Command to check the Data Flash IFR Map EEPROM data set size value [EEESIZE]. I have checked during Flash program phase if there with JTAG Mass erase operation, the Data Flash IFR EEESIZE was erased to 0xFF value, that means customer can do Program Partition Command.

Having returned to this problem of DEPART = 0x0B after mass erase using P&E micro multilink universal I thought I would try upgrading from CW10.4 to CW 10.6. Bingo! DEPART is now erased to 0x0F and programming partition now works just fine. I thought I would share this :-)