AnsweredAssumed Answered

MCUBOOT flash failing when enabling FlexNVM as Enhanced eeprom in K66

Question asked by Øystein Holt on Dec 10, 2018
Latest reply on Dec 12, 2018 by Øystein Holt
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-microcontroller/). 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:

Outcomes