mirror of https://github.com/ARMmbed/mbed-os.git
8f77de6453
In case our are contains data from previous reset() or reset_area(), we might end up in the situation where free space contains valid key headers, but we have not erased that area yet. This can cause failures if the deinit() and init() because new scan of that area would continue as long as keys are found. This causes keys on the not-yet-erased area to be included in the new instance of TDBStore. To prevent this failure, check after each key-write that our free space does not contain valid key headers. Also make sure that we erase one program unit sector over the master record. If we erased just the master record,first key might is still there, causing next init() to find it. Extend erase area by one program unit, so that build_ram_table() won't find any keys. |
||
|---|---|---|
| .. | ||
| conf | ||
| direct_access_devicekey | ||
| filesystemstore | ||
| global_api | ||
| include | ||
| kv_map | ||
| securestore | ||
| tdbstore | ||