Issue with features-storage-tests-blockdevice-general_block_device

[miteshdedhia7]

Description of defect

BUG: The test_random_program_read_erase and test_thread_job and potentially other tests in features-storage-tests-blockdevice-general_block_device test query the block_size using get_erase_size(). For a QSPIFBlockDevice, when using the sector map table the
get_erase_size()/_min_common_erase_size is calculated by checking if all sectors have a common erase type in _sfdp_parse_sector_map_table(). If all sectors in a Flash device do not have a common erase type (which may be a valid use case) then get_erase_size() returns 0 and the the tests will fail since block_size == 0 with nothing to erase, program or read. Note that _sfdp_detect_erase_types_inst_and_size also sets the _min_common_erase_size but this is overriden by _sfdp_parse_sector_map_table() which was never called before due the bug in header parsing mentioned before.

Target(s) affected by this defect ?

CYW9P62S1_43012EVB_01 (Potentially other targets)

Toolchain(s) (name and version) displaying this defect ?

All Toolchains

What version of Mbed-os are you using (tag or sha) ?

fe12608

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.2

How is this defect reproduced ?

Related to issue #11722

[adbridge]

@miteshdedhia7 mbed-os-99.99.99 just indicates that you are using master and doesn't narrow the problem down to a specific point. Could you please provide the actual sha of the version you have found the issue on (in the template) ? Thanks

[ciarmcom]

@miteshdedhia7 thank you for the update.It appears however that there is still some missing information:

Have you correctly specified which version of Mbed OS you are using (tag or sha)? We cannot automatically identify a release based on what you have provided.

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2588

[LDong-Arm]

Hi @miteshdedhia7, sorry for the delayed response. I generally agree with your analysis.

If all sectors in a Flash device do not have a common erase type (which may be a valid use case) then get_erase_size() returns 0

Yes, returning 0 is a defined behaviour. I've created #13552 so that the test doesn't rely on get_erase_size() (no parameter) or a common erase size.
But I don't have a board (with SFDP + non-uniform flash layout) to test during work-from-home. Would you please have a try if possible? Thanks in advance.

Note that _sfdp_detect_erase_types_inst_and_size also sets the _min_common_erase_size but this is overriden by _sfdp_parse_sector_map_table()

_sfdp_detect_erase_types_inst_and_size sets an initial value of _min_common_erase_size, just in case no sector map table exists. If a sector map table does exist, then _sfdp_parse_sector_map_table() checks which region supports which erase size(s) and whether a common size exists for all regions, for a final conclusion.

which was never called before due the bug in header parsing mentioned before.

This refers to #12574? I agree it's a missing feature we consider adding, so we can't say CYW9P62S1_43012EVB_01's flash is fully supported for now I'm afraid. But you might still be able to run my fix for the test.

Thanks again for raising and investigating those issues!

[LDong-Arm]

@miteshdedhia7 This issue was automatically closed by the merging of my PR. But please feel free to have a try and tell us how it goes. We can reopen it if it doesn't work.