K10 FlexMemory FCFG1 EESIZE initial value

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K10 FlexMemory FCFG1 EESIZE initial value

1,017 Views
michaelkonieczn
Contributor II

Chip in question: MK10DX256VLL7, mask 3N36B.

I'm trying to use FlexNVM/FlexRAM memories, and to configure it, one must send Program Partition Command. Only once for particular application, so I'm trying to decide whether to call it in init sequence depending on current FCFG1 register EESIZE and DEPART fields values - if they are set as expected, then I assume it's already configured. If they are not, then I do the initial configuration.

But after 'mass erase' via EzPort, I get unexpected value of FCFG1.EESIZE field == 0011, meaning 2048 bytes for EEPROM. I expect 1111 there, meaning no EEPROM.
Data flash IFR has a EESIZE field, that determines EEPROM size. Erased state should be all 1s and that value should propagate to FCFG1.
Let's assume that IFR.EESIZE gets value 3 out of mass erase. Then later reprogramming attempt shoud fail with ACCERR, according to the manual (condition is: The EEPROM data size and FlexNVM partition code bytes are not initially 0xFFFF). But it gets programmed successfully, to any valid value. Next attempt (without mass erase) to program IFR.EESIZE fails, as expected. So, it suggests that initial value (after mass erase) of IFR.EESIZE is indeed all 1s, as it allows programming, once. I can set any valid value for EESIZE and it gets propagated via FCFG1 properly. Only initial value of all 1s (out of mass erase) gets propagated to FCFG1.EESIZE incorrectly, as value == 3.

A bug, or am I missing something?

Labels (1)
8 Replies

713 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi

Which command you are using to do "Mass erase" via EzPort?

If customer calls the "Bulk Erase" EzPort command?


Thank you for the attention.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

713 Views
michaelkonieczn
Contributor II

Yes, it's "Bulk Erase" command, issued over EzPort. I wrote "Mass Erase" because manual uses there terms somewhat inconsistently, in other places it's Mass Erase.

No, the customer doesn't use EzPort, I use it as a developer. Unless you call me the customer, as a customer of Freescale/NXP/Qualcomm/whatever comes next.
I'll add that after Bulk Erase, setting IFR.EESIZE to all 1111 via Program Partition Command succeeds, so it clearly is erased prior to that operation. But before and after that, FCFG1.EESIZE has value == 3. Setting IFR.EESIZE to any other valid value is properly reflected in FCFG1.EESIZE. Except the value of 1111.

0 Kudos

713 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi

The EzPort "Bulk Erase" command doesn't affect the Data Flash IFR memory values.

And the SIM_FCFG1 register will load the value from Data Flash IFR after chip reset.

If you modify the EESIZE value via Program Partition Command after the chip reset , the SIM_FCFG1 doesn't updated the [EESIZE] bits value after the next round reset happens.

So, you could reset the chip and check if SIM_FCFG1 register [EESIZE] bits with expected 0b1111 value.


Wish it helps.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

713 Views
michaelkonieczn
Contributor II

> If you modify the EESIZE value via Program Partition Command after the chip reset , the SIM_FCFG1 doesn't updated the [EESIZE] bits value after the next round reset happens.

That also doesn't seem to be true.

Just checked, and for my MCU it's like this - values of FCFG1 before and after Program Partition Command (when setting EESIZE = 9 and DPART = 2):

(here we come after Bulk Erase and program flash programming)

0000000000.143 FCFG1=39030F00

(here comes Program Partition Command)
0000000000.175 FCFG1=39090200

So, just after Bulk Erase and before Program Partition Command, FCFG1 value is 39030F00 - so EESIZE == 0x3 and DEPART= 0xF.

After Program Partition Command, FCFG1 value is 39090200 - so EESIZE == 0x09 and DEPART == 0x2.

What we have here:

EESIZE changed value from 0x3 to 0x9 (0b0011 -> 0b1001) - bit #3 gets set, should be impossible to happen, as we program FLASH cell and only erasure can change 0->1.
DEPART gets changed correctly.

Next Bulk Erase restores FCFG1=39030F00, so it clearly affects IFR - DEPART becomes erased, EESIZE also (it can be reprogrammed to any value), only FCFG1.EESIZE == 3 remains a mystery.

And FCFG1 gets correctly updated just after Program Partition Command, without next chip reset being required, as can bee seen from my experiment. It doesn't require another reset, as you've stated.

713 Views
michaelkonieczn
Contributor II

> The EzPort "Bulk Erase" command doesn't affect the Data Flash IFR memory values.

I don't think so.

After Bulke Erase, I can set IFR.EESIZE to any value. So it obviously must be erased prior to that, otherwise Program Partition Command shoud fail with FSTAT.ACCERR, according to the manual (manual page 621: The EEPROM data size and FlexNVM partition code bytes are not initially 0xFFFF). And this command succeeds, and succeeds only once without next Bulk Erase - it's impossible to reprogram it if it's already set to something else than 1111, and then I get FSTAT.ACCERR. As expected, according to the manual. But after next Ezport Bulk Erase, I can program IFR.EESIZE to any value again. So, it clearly must be erased during Bulk Erase.

0 Kudos

713 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi

First of all, sorry for my delayed reply.

I had done a test with TWR-K20D72M board, which with PK20DX256VLL7 mask set 1N36B mounted.

After I using the J-Link tool unlock (external mass erase) the K20 chip, the reset value of SIM_FCFG1 register value as below picture shows:

pastedImage_1.png

As your mentioned, the SIM_FCFG1 register [EESIZE] value is 0x3.

In fact, The EEPROM default value 0x3 does not affect the Flash Program Partition Command operation.

I had done the test to validate it works.

The SIM_FCFG1 & SIM_FCFG2 registers value will be modified during Flash Program Partition Command execution.

I debug the code and find those registers value changed as below picture shows:

There does not need a reset before SIM_FCFG1 & SIM_FCFG2 registers update the value.

Sorry for my previous answer about it.

pastedImage_2.png

I am using below code to check FlexNVM had been partitioned or not:

      /* Test to make sure the device is not already partitioned. If it
       * is already partitioned, then return with no action performed.
       */
      if ((SIM_FCFG1 & SIM_FCFG1_DEPART(0xF)) != 0x00000F00)
      {
          printf("\nDevice is already partitioned.\n");
          return 0;
      }


Wish it helps.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

713 Views
michaelkonieczn
Contributor II

So, you have just confirmed my observations.

Still, that behaviour is undocumented and doesn't have any sense. Unless I'm missing something.

Hence my question again:

Is this a bug, or some undocumented intention? As you represent NXP, maybe you could ask someone who knows...

0 Kudos

713 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi

There is an errata record about SIM_FCFG1 register reset value for mask set 1N36B:

pastedImage_1.png

I am using the mask set 1N36B chip do the test and observed behavior was caused by this errata.

While, I don't have mask set 3N36B chip on hand.

I need to double check with Kinetis product team if this errata was fixed or not.

For, so far from mask set 3N36B errata file, this e6272 record was removed.

I will let you know when there with any feedback. Thank you for the patience.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos