Please be informed that if power failure occurs after the actual data writing process has completed, then there is no problem, and the data would be stored correctly.
However, if power failure occurs, when the data was actually being written, then the data would not be stored in the A&D memory. In this case, the internal tables which manage the data that is written to the A&D will not be updated, and hence, after power on, if the application checks for the A&D data existence, then error would be returned by the ADL library.
In other words, adl_adWrite () is a blocking API. If this API returns from the execution, then it means that the data has been correctly written. But if this API has not yet returned, and the power was lost then it means that data was not written, and the application on startup, can check again, the existence of data on the a&d location.
If no data was written, then the data could be written again. Internally, only if the data is correctly written, then only an internal table is updated in the flash, that indicates, that the data is valid in a specific A&D location.
In case, of power loss, the table would not be updated, and hence, you can be sure, that the data is not written.
Hence, the data write state is either NOT WRITTEN or WRITTEN. There is no intermediate state of inconsistency.
In Open AT application framework, there is a feature called uninitialized RAM, where if there is an unexpected power loss (due to reset), then the data is not lost. You can use this storage, and then compare the contents of this storage and the A&D for consistency to be sure, that all the data is correctly written even in case of reset due to exception.