AnsweredAssumed Answered

MK22DX128M5 - FlexNVM configuration, PEMicro Multilink

Question asked by J Stark on Nov 23, 2018
Latest reply on Nov 27, 2018 by J Stark

I'm trying to configure the FlexNVM block on an MK22DX128M5 micro using a PEMicro Multilink debug interface. I'm currently running MCUXpresso IDE v10.1.1 [Build 606] [2018-01-02] under Mint 18, which is based upon Ubuntu 16.04.1. For my application, I want to allocate the full 64 k flash block for EEPROM storage, 64 bytes of FlexRAM with 1/4 assigned to subsystem A and 3/4 assigned to subsystem B. These configuration parameters correspond to the following settings if I'm interpreting the Reference Manual correctly:

EESPLIT: 2'b01

EESIZE: 4'b1000

DEPART: 4'b0100 or 4'b1011

 

In the Debug pulldown -> Debug Configurations... -> Debugger dialog, I'm selecting "Emergency Kinetis Device Recovery by Full Chip Erase" under Addtional Options. In the Advanced Options dialog, I select "Enable partitioning for the device", with a value of 1804. If I then click "OK" to close the Advanced Options dialog, then "Apply" followed by "Debug" on the Debugger Configuration dialog, the device is programmed and I will eventually end up in the debugger.

 

Following this sequence, I do not see that the device is configured as expected. Inspecting the EEPROM Data Set Size and FlexNVM Partition Code registers at addresses 0xfd and 0xfc, respectively, I find values of 0x05 and 0x71. Neither makes sense and write operations to FlexRAM are not preserved across power cycles.

 

It's not clear to me that I'm attempting to use the configuration tool provided by the debugger correctly, so that may be the root of the problem. Since I can type the string "abcd" into the partitioning code dialog window but not "0x1804" nor the decimal equivalent of that value, I presume that the value I do enter is in fact hexadecimal. Also, the Erase Options pulldown on that page is always grayed-out, so perhaps attempts to erase the value presently stored in the flash IFR are being ignored or rejected. I've also noted that the values stored at addresses 0xf0, 0xf4 and 0xf8 are 0x00000559, 0x0000561, 0x000000569, respectively, so the value 0x00000571 that I'm seeing could possibly be part of a pattern.

 

Any assistance in understanding this process or guidance which will enable me to perform this configuration successfully will be most appreciated.

Outcomes