Improve user experience with Shadow mode

[doegox]

When in Shadow mode, the device will not store current MF1 slot changes when changing slot or going to sleep. This is expected for the MF1 card content, this is less expected for the MF1 settings (changing mode, changing gen1a support,...).

Current workaround is to set again Shadow mode when one wishes to change and save MF1 settings in shadow mode, e.g.

# start from a wake up, to get original MF1 content and settings
hf mf settings --gen1a 1
hf mf settings --write 3     <-- this will move it to SHADOW_REQ and authorize the save to flash
hw slot update

Solution could be to split slot settings and slot data in two separate files, so slot settings can be saved to flash independently of the MF1 mode, being Shadow or not.

[xianglin1998]

Is it a feasible solution to split the file structure without splitting the memory structure?

[xianglin1998]

FDS read file implement in fds_util.c, is read from flash from file start address to file end, if we can given params to read file from offset & max length, maybe read old mf1 data from flash to reset data memory is a good solution?

And we can using 32byte to store all block modified history, if bit == 1, the block is changed. before save data on ShadowMode device check all bit field, when bit == 1, reset it(MF1 Block Data).

Note: I originally designed only one buffer to store all configuration and critical data in order to avoid maintaining too many file resources. If there is a need to backup or transfer data, I only need to read the flash once.

@doegox

[xianglin1998]

Is it a feasible solution to split the file structure without splitting the memory structure?

Try to avoid splitting files as much as possible

[doegox]

Yes it can be a solution. Beware there is a side effect on DATA_CMD_SLOT_DATA_CONFIG_SAVE with shadow: if you read MFC data from flash and overwrite RAM version, the user will lose its current shadowed RAM content. In practice it's probably not much of a problem but it is quite unexpected for the user to get RAM data changed on a hw slot store.

I don't know if maintaining a history bit is really needed, reading flash doesn't cost much.

IMHO It is more an issue to issue a large flash write to write all MFC data (even if unchanged), up to 4k for mfc 4k, every time a single bit of the MFC config or anticoll is changed... That's why I suggested to maintain 2 files.

[doegox]

Try to avoid splitting files as much as possible

why so? I may have overlooked something here. Note that we've already 16 files for the nicknames alone...

[xianglin1998]

Try to avoid splitting files as much as possible

why so? I may have overlooked something here. Note that we've already 16 files for the nicknames alone...

This is indeed very reasonable, as frequent configuration changes can reduce the lifespan of the flash. So i do not recommend splitting files because of compatibility issues and coding difficulty issues. But if compatibility issues can be solved, we can ignore the issue of coding difficulty.

[xianglin1998]

Splitting is not recommended simply because I want to avoid trouble. Hahaha, but if necessary, we can try to solve the trouble of splitting files.