MCUBOOT flash failing when enabling FlexNVM as Enhanced eeprom in K66

[oystein_olsen_h]

I'm using the mk66fx1m0vmd18 with Teensy 3.6 hardware as the development board. The software is based on the Freedom MK66F board bootloader example code (freedom_bootloader) adapted to the eeprom version of the chip (with inspiration from https://mcuoneclipse.com/2018/03/03/flash-resident-usb-hid-bootloader-with-the-nxp-kinetis-k22-micro...). The main application is a C++ project application with FreeRTOS starting from address 0xA000. It's based on the example at https://mcuoneclipse.com/2018/05/27/tutorial-understanding-and-using-freertos-software-timers/, basically just blinking a led and listening to communication over USB (high speed).

I'm currently using the KinetisFlashTool via USB HID for uploading new application firmware and disabled all other interfaces. I've modified the code and hardware, so when pressing the push button on the Teensy 3.6 when applying power to the board it will stay in the bootloader and waiting for communication from the KinetisFlashTool. However, I'd like to use the eeprom instead to check if the bootloader should wait for a firmware update, or jump directly to the application. 

The MCUBOOT code works without any issues as long as the eeprom functionality is not configured either dynamically using the eeprom_initialization() from the Teensy core library, or configuring via the PE Micro Multilink Universal when programming the chip. But as soon as either eeprom_initalization() is run either in the application or in the bootloader, or if the chip is programmed with the eeprom enabled (no other changes to the code or configuration is done), attempting to updating of the application in flash using the bootloader will cause a HardFault and end up in the HardFault_Handler() when writing to flash (at latest at address 0xA3E0):

Rebooting the board will keep it in the bootloader, but reattempting flashing the application again will result in the same HardFault. When debugging, it seems like the program flash from address 0xA000 is correctly erased (set to all FF's).

I've checked the relevant registers both with eeprom enabled and not, and see no difference except from the registers defining the eeprom configuration. I've also verified that the system clock is set to 120 MHz. Doing a full erase and not programming the eeprom functionality gets the bootloader flashing working properly again.

I've checked and tested a lot of input from this site and others related to linker setup, bootloading, flash protection etc, without any success. It may be a very obvious reason for this failing, however I'm so far not able to figure out what is causing this. Again, the only difference is enabling FlexNVM as eeprom. And the eeprom functionality works; I can read and write to eeprom.

Any help to nudge me in the right direction to solve this issue would be highly appreciated!

Some more details:

• I'm using MCUXpresso IDE v10.2.1 [Build 795] [2018-07-25].
• The debugger is PE Micro Multilink Universal rev B with the latest firmware.
• The main application us using a managed linker script, while the bootloader is using the manually configured linker file from the example project. The only change done to the bootloader linker script is that I've added the memory area for FlexNVM as described here: https://freescale.jiveon.com/docs/DOC-341716 to attempt to make the flashing work.
• I'm using "EEE memory configuration example 2 — maximum EEE" as described on from page 8 in https://www.nxp.com/docs/en/application-note/AN4282.pdf. This means that the partition code is 3208:
  

[jingpan]

Hi,

the screenshot of the Advanced options is made by P&E and integrated into MCUXpresso. I'm not sure how it works. It says "EEPROM data set size must be within 0x00...0x3f". What does it mean? Can you try to read data flash 0 IFR map to see if the setting is correct? Sometimes incorrect setting may cause hardfault. For example, if the EEE size is configured as 32 bytes total, then read or write accesses to any addresses between 0x1400_0000 and 0x1400_001F are allowed, but 0x1400_0020 to 0x17FF_FFFF generates a bus error.

Also, please pay attention to 3.3.1 in AN4282, improper writing also cause hardfault.

You can download MCUBoot from https://www.nxp.com/support/developer-resources/software-development-tools/mcuxpresso-software-and-t...

It has K66 bootloader. You can try this one.

Regards,

Jing

[oystein_olsen_h]

Hi,

Thanks for the reply. Responding to your input in reverse order:

MCUBOOT: I'm using MCUBOOT from SDK version 2.4.1 for this version of the chip. I assume that it's the same as the link you're providing?

I've read AN4282 and am aware of improper writing will cause a hardfault. 

I might have been unclear in my first post, but the issue with hardfault happens regardless of actually reading or writing to eeprom using the FlexMemory feature. When I first encountered the issue, there was no code in the bootloader that did any reading or writing to eeprom.

Also note that reading/writing to eeprom works ok in the application and I have had no hardfaults when doing that. 

The issue occurs after the FlexNVM has been configured to using it as eeprom and the register EEERDY in FTFE-FCNFG has been set. It happens both when using the P&E Micro Advanced options feature as shown in the picture in my first post or configuring it from the code using the program partitioning command, and if done either in the bootloader or application.

I'm not quite sure how to read the data flash 0 IFR, is there a way to do it using the debugger? Or another method to read it directly?

Anyway; here is a dump of the SIM-FCFG1 register when EEE is configured which according to my understanding seems to be correct:

So just to summarize; the issue is not reading/writing to eeprom, but as soon as FlexNVM is configured to be used as eeprom (EEERDY is set), when the bootloader attempts to write (a application) to flash from address 0xA000, a hardfault occurs. It has then successfully erased flash from 0xA000, so there is no application to jump to. The bootloader is still present and will run also after a reboot, but will not be able to flash a new application.

The first part of the FTFE registers then look like the following:

There doesn't seem to be any access or protection violations.

This means that I can program the device with a bootloader (no application) and EEEPROM not enabled, and the successfully load a new application. I can then also run the program partitioning command and still successfully reboot to the application again. However, if I then try to load a new application via the bootloader, the application part of the flash is erased, but I'm not able to write the application due to the hardfault. I then need to use the debugger to erase the whole program flash and write the bootloader/application again.

I hope I've described the problem somewhat better now.

[jingpan]

Hi,

1. I see that hardfault happens at a memcopy() each time. Please check what/where/how long does it copy?

2. After you config the eeprom, you can test if the eeprom is work well. For example, fill the eeprom and then power off and power on. Is the data still there?

Regards,

jing

[oystein_olsen_h · Accepted solution]

Hi,

I've got it working now. It was a wrong configuration of the CPU type causing this. In the bootloader project preprocessor settings, "CPU_MK66FN2M0VMD18" and 

"CPU_MK66FN2M0VMD18_cm4" were defined (i.e. the version w/o EEEPROM functionality and which is used in FRDM-K66F board), and not "CPU_MK66FX1M0VMD18 and "CPU_MK66FX1M0VMD18_cm4" as it should be.

In the function FTFx_CMD_ProgramSection(), I see that the FlexRAM is used for the data to be written to flash. The memcpy fails due to not being reconfigured to be used as RAM but instead as EEEPROM during flashing when using the incorrect CPU definition (the comment before the call to memcpy gave me the hint I needed).

I've verified that the eeprom works correctly as intended in the application, and it seems like it works in the bootloader as well (need more testing, though).

To me, this is a new processor family, so there are a lot of moving parts to grasp...

Thanks for putting me on the right track to solve this issue!