If the fault handler was hit before the stdio console was used and
initialised, the initialisation code caused a "mutex in ISR" trap,
stopping the register dump from happening.
Temporarily set the `error_in_progress` flag at the top of the fault
handler, and restore it before calling `mbed_error`. Take the
opportunity to suppress fault dumps on recursive crashes, much as is
done inside `mbed_error`.
Previously Greentea tests was not initialising its storage
before asking for bd->get_program_size(), causing FlashBlockDevice to
return zero. This caused both TDBStorage's to use zero for both
parameter to SlicingBlockDevice(bd, 0, 0), effetivaly both then
used same addresses for slice. This caused SecureStore tests
to fail, because writes to internal RBP storage overwrote keys
from external storage.
Fine-tune TDBStore sizes, so that all tests can fit into storage.
At least with LPC55S69's default TDBStore configuration it's
impossible to run storage Greentea tests without exhausting the
memory reserved for storing keys.
Fixes an issue where number of keys were removed based on number of
threads which didn't have anything to do with the test case.
Fixes an issue where number of keys were assumed to be constant
but variable number was used for configuration.
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.