You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The writeSlot method expects the first byte of data to never be zero. Under regular use, this is always the case.
However, when the address erase scheme is created on top of an area previously used by another scheme, and the application has not re-initialized the storage space, the flash will still contain data from the previous scheme, which is not valid for the address erase scheme.
The quick fix is to avoid the hang, so that the scheme behaves more robustly in the face of unexpected data. The tests TEST(MultiWriteSlotAccess, writeSlot_invalid_bitmap) and TEST(MultiWriteSlotAccess, readSlot_invalid_bitmap) have been created to express the problem and verify the fix. Prior to the fix, the code would hang.
As well as strengthening the code for unexpected data, the system should try to auto-detect when a region has been used for something else previously. This can be done by writing the configuration data to the housekeeping page. If this doesn't match the current configuration, then the system can automatically erase the area, since the data will not be valid.
The text was updated successfully, but these errors were encountered:
m-mcgowan
changed the title
detect change in config and erase data
detect change in storage scheme and erase data as needed
Aug 4, 2014
The
writeSlot
method expects the first byte of data to never be zero. Under regular use, this is always the case.However, when the address erase scheme is created on top of an area previously used by another scheme, and the application has not re-initialized the storage space, the flash will still contain data from the previous scheme, which is not valid for the address erase scheme.
The quick fix is to avoid the hang, so that the scheme behaves more robustly in the face of unexpected data. The tests
TEST(MultiWriteSlotAccess, writeSlot_invalid_bitmap)
andTEST(MultiWriteSlotAccess, readSlot_invalid_bitmap)
have been created to express the problem and verify the fix. Prior to the fix, the code would hang.As well as strengthening the code for unexpected data, the system should try to auto-detect when a region has been used for something else previously. This can be done by writing the configuration data to the housekeeping page. If this doesn't match the current configuration, then the system can automatically erase the area, since the data will not be valid.
The text was updated successfully, but these errors were encountered: