Solved! Go to 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!
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
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.
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
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!