2025-08-12 2:41 PM
Hello,
Sometimes saving to flash takes the devices a couple of seconds.
It enters through APP_ZIGBEE_persist_save() -> APP_ZIGBEE_NVM_Write() -> EE_Write -> EE_Transfer -> EE_ReadEl; and takes a while in this function.
Occasionally, the device enters the NMI handler in this same function.
Is anyone aware of these issues?
Thanks,
2025-08-22 1:59 AM
Hello,
The NVM is split in two banks. Each bank may have several sectors. One bank holds the valid (and obsolete) data whereas the other one is used for the "Bank Transfer" mechanism when the running Bank is full.
The algorithm implemented in EE_Transfer() is long to be executed when the amount of valid data to be transfered is close to the size of the Bank. However, I would expect this long time to happen on each EE_Transfer() call and not from time to time. Maybe there is something wrong during execution and the NVM module believes there is a large amount of valid data to be transfered.
If your amount of data to be saved is almost the size of the Bank, you should increase the Bank size to be at least twice bigger than the amount of valid data to be hold in NVM.
For the time being, I see no other reason why this could be long.
Regarding the NMI issue, there is a high probability that you are facing an ECC error. When any of the two CPUs reads a flash line that holds an ECC issue, this will generate an NMI on both CPU1 and CPU2.
Based on my understanding of your application, there is likely something wrong in the NVM and the NMI is generated when CPU1 reads data from NVM.
You can check the FLASH_ECCR register. You will find there the CPU ID that generated the NMI and the faulty address in Flash.
If it is confirmed to be an ECC error in NVM, there are mainly two reasons "
- Flash is end of life. 10000 erase cycles are supported on each sector. Once you will go over that limit, the flash behavior is not committed anymore.
- You may have faced a power down during flash programming.
Regards.