-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TDBStore refactoring #11987
TDBStore refactoring #11987
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
@SeppoTakalo, thank you for your changes. |
Change the "reserved data" logic so that every time we erase and area, the content of reserved data is then immediately copied to newly erased area. This keeps two copies of the data. When data is requested, return only if checksum is matching. When data is written, only allow if BOTH checksums are incorrect, meaning that areas are either corrupted or erased. Only exception is TDBStore::reset() which erases all keys and reserved data. Removed all logic that tried to detect, if reserved are was erased or corrupted. Rely entirely on checksum. Add moduletest for reserved data.
Previous logic caused garbage collection to kick in, if the init() was called on empty storage. This has effect of erasing areas twice, if both areas were empty. Re-write logic so that we erase areas only on garbage_collect() or reset(). The init() logic already chooses the active area, so no need to touch, until keys are modified. Removed also the is_erase_unit_erased() as this is working only on FLASH devices, and TDBStore should be refactored to work on all storages.
TDBStore used to rely on Flash devices erase value. This logic has been removed, and TDBStore can do the entire erase logic itself, in case the given BlockDevice does not offer erase(). This relies on BlockDevice to properly return -1 in BlockDevice::get_erase_value().
e79de64
to
ce7b196
Compare
Cherry-picked two commits from #11986 which should also fix the failing test case here. Rebased and started a test run. |
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
Failed test |
@SeppoTakalo You could have just restarted greentea test (exporters, test after build OK can be restarted separately), all restarted is also fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
@VeliMattiLahtela Any idea why TCP tests on F429ZI are now failing? |
Looks like network problem as all failed on the first run, second run is all good |
Yes, verified from CI room that ethernet cable was unplugged. |
Copy over the TDBStore.cpp|.h as they contain a few bug fixes which we seem to be needing (in some corner cases). The files are copied over from Mbed OS master at the tip of master as of today, hash pointing at 2f87d59. This brings in a number of changes, but primarily we are interested in this: ARMmbed#11987 Device 943 ended up in a state, where it would not boot up and in the debug image I was able to spot it died in the TDBStore.cpp, 00> ++ MbedOS Error Info ++ 00> Error Status: 0x80FF011B Code: 283 Module: 255 00> Error Message: TDBSTORE: Unable to build RAM table at init 00> Location: 0x71347 00> Error Value: 0x0 00> Current Thread: main Id: 0x20012C68 Entry: 0x7482F StackSize: 0x1400 StackMem: 0x200168E8 SP: 0x20017AEC 00> For more info, visit: https://mbed.com/s/error?error=0x80FF011B&tgt=EPEN3 This is due to corrupted QSPIF. This should prevent that from happening or at least recover from it in a more sensible way, as it will not "guess if it's been erased or not", but more deterministily just erase properly. Device was recoverable even with existing SW by forcing an erase in the error branch, patch below: --- start of patch: ``` diff --git i/features/storage/kvstore/tdbstore/TDBStore.cpp w/features/storage/kvstore/tdbstore/TDBStore.cpp index efeedf42c2..701ce7d044 100644 --- i/features/storage/kvstore/tdbstore/TDBStore.cpp +++ w/features/storage/kvstore/tdbstore/TDBStore.cpp @@ -1027,6 +1027,7 @@ int TDBStore::init() } #endif + printf("_bd.type == %s\n", _bd->get_type()); _max_keys = initial_max_keys; @@ -1097,6 +1098,7 @@ int TDBStore::init() // In case we have two empty areas, arbitrarily use area 0 as the active one. if ((area_state[0] == TDBSTORE_AREA_STATE_EMPTY) && (area_state[1] == TDBSTORE_AREA_STATE_EMPTY)) { + printf("active area = 0\n"); _active_area = 0; _active_area_version = 1; ret = write_master_record(_active_area, _active_area_version, _free_space_offset); @@ -1115,6 +1117,7 @@ int TDBStore::init() } else { _active_area = 1; } + printf("active area = %d\n", _active_area); _active_area_version = versions[_active_area]; ret = reset_area(1 - _active_area); if (ret) { @@ -1128,6 +1131,11 @@ int TDBStore::init() ret = build_ram_table(); if ((ret != MBED_SUCCESS) && (ret != MBED_ERROR_INVALID_DATA_DETECTED)) { + printf("TDBSTORE: Unable to build RAM table at init - try erase area!"); + ret = reset_area(0); + printf("reset_area(0))=%d\n", ret); + ret = reset_area(1); + printf("reset_area(1))=%d\n", ret); MBED_ERROR(ret, "TDBSTORE: Unable to build RAM table at init"); } @@ -1159,6 +1167,7 @@ int TDBStore::init() } end: + printf("TDBStore init() done for %s\n", _bd->get_type()); _is_initialized = true; _mutex.unlock(); return ret; ``` --- end of patch
Since ARMmbed/mbed-os#11987 was merged to Mbed OS, a flash device or a simulated flash device is no longer a requirement.
This is not just a feature request, this is actually a bug fix in many respects. |
Description
Summary of change
Small fixes, refactoring and one functionality change to TDBStore:
Assuming underlying device was FLASH device was error prone, as we cannot trust erase values. Logic has changed to that we always erase before writing to new area.
Documentation
We can remove then requirements from documentation that
TDBStore
would require FLASH device. After these changes, it does not anymore.More module+unit tests have been implemented but can only be submitted once Mbed CRC changes are submitted into master.
Pull request type
Test results
Reviewers
@VeijoPesonen
Release Notes
Summary of changes
TDBStore
does not anymore require Flash based block device.Impact of changes
Migration actions required