Currently (and very confusingly), the SDBlockDevice implementation defaults to a "no-op" when calling erase on it. In some cases, the code is expecting a particular value once the device is erased.
I know, I know, the documentation specifically mentions this. I swear it has not always been like this (it's too late and I'm too lazy to go check the git blame). I have been using Mbed-OS and the SDBlockDevice for years... I've never encountered this issue.
Anyways, I think it would be appropriate to provide a configuration option that allows the user to decide if erase is a no-op or not. If not, they must provide an erase value that is then programmed to the SDBlockDevice.
In my case, I'm making a bootloader for the K64F that is built with MCUboot. MCUboot expects certain areas of flash to be their "erased" values, otherwise bad things :TM: happen.
Target(s) affected by this defect ?
All
Toolchain(s) (name and version) displaying this defect ?
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
What version of Mbed-os are you using (tag or sha) ?
mbed-os-99.99.99
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
Description of defect
Currently (and very confusingly), the
SDBlockDevice
implementation defaults to a "no-op" when callingerase
on it. In some cases, the code is expecting a particular value once the device is erased.I know, I know, the documentation specifically mentions this. I swear it has not always been like this (it's too late and I'm too lazy to go check the git blame). I have been using Mbed-OS and the SDBlockDevice for years... I've never encountered this issue.
Anyways, I think it would be appropriate to provide a configuration option that allows the user to decide if erase is a no-op or not. If not, they must provide an erase value that is then programmed to the SDBlockDevice.
In my case, I'm making a bootloader for the K64F that is built with MCUboot. MCUboot expects certain areas of flash to be their "erased" values, otherwise bad things :TM: happen.
Target(s) affected by this defect ?
All
Toolchain(s) (name and version) displaying this defect ?
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
What version of Mbed-os are you using (tag or sha) ?
mbed-os-99.99.99
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
How is this defect reproduced ?
Use code that relies on a particular erase value with an underlying SDBlockDevice.