|void||halSimEepromCallback (EmberStatus status)|
|The Simulated EEPROM callback function, implemented by the application. |
These callbacks were contributed by the sim-eeprom API.
An EmberStatus error code indicating one of the conditions described below.
This callback will report an EmberStatus of EMBER_SIM_EEPROM_ERASE_PAGE_GREEN whenever a token is set and a page needs to be erased. If the main application loop does not periodically call halSimEepromErasePage(), it is best to then erase a page in response to EMBER_SIM_EEPROM_ERASE_PAGE_GREEN.
This callback will report an EmberStatus of EMBER_SIM_EEPROM_ERASE_PAGE_RED when the pages must be erased to prevent data loss. halSimEepromErasePage() needs to be called until it returns 0 to indicate there are no more pages that need to be erased. Ignoring this indication and not erasing the pages will cause dropping the new data trying to be written.
This callback will report an EmberStatus of EMBER_SIM_EEPROM_FULL when the new data cannot be written due to unerased pages. Not erasing pages regularly, not erasing in response to EMBER_SIM_EEPROM_ERASE_PAGE_GREEN, or not erasing in response to EMBER_SIM_EEPROM_ERASE_PAGE_RED will cause EMBER_SIM_EEPROM_FULL and the new data will be lost!. Any future write attempts will be lost as well.
This callback will report an EmberStatus of EMBER_SIM_EEPROM_REPAIRING when the Simulated EEPROM needs to repair itself. While there's nothing for an app to do when the SimEE is going to repair itself (SimEE has to be fully functional for the rest of the system to work), alert the application to the fact that repairing is occuring. There are debugging scenarios where an app might want to know that repairing is happening; such as monitoring frequency.
- Common situations will trigger an expected repair, such as using a new chip or changing token definitions.
If the callback ever reports the status EMBER_ERR_FLASH_WRITE_INHIBITED or EMBER_ERR_FLASH_VERIFY_FAILED, this indicates a catastrophic failure in flash writing, meaning either the address being written is not empty or the write itself has failed. If EMBER_ERR_FLASH_WRITE_INHIBITED is encountered, the function ::halInternalSimEeRepair(false) should be called and the chip should then be reset to allow proper initialization to recover. If EMBER_ERR_FLASH_VERIFY_FAILED is encountered the Simulated EEPROM (and tokens) on the specific chip with this error should not be trusted anymore.
References assert, EMBER_ERR_FLASH_VERIFY_FAILED, EMBER_ERR_FLASH_WRITE_INHIBITED, EMBER_SIM_EEPROM_ERASE_PAGE_GREEN, EMBER_SIM_EEPROM_ERASE_PAGE_RED, EMBER_SIM_EEPROM_FULL, EMBER_SIM_EEPROM_REPAIRING, halInternalSysReset(), halSimEepromErasePage(), and halSimEepromPagesRemainingToBeErased().