Each block of HeapBlockDevice is only allocated from the heap when
that block is programmed. And erasing a block frees the associated
buffer.
To decide if there is enough heap to run the TDBStore Whitebox tests,
we need to perform a trial program() instead of erase().
From the documentations of `BlockDevice::get_erase_value()`:
-1 if you can't rely on the value of the erased storage
and `BlockDevice::program()`:
The blocks must have been erased prior to being programmed
So, `BlockDevice::erase()` should always be called regardless of
erase value.
Currently `TDBStore::offset_in_erase_unit()` and
`TDBStore::check_erase_before_write()` loop through erase units
one-by-one, until the entire range is covered. This is very inefficient
when the erase size is tiny, e.g. one-byte on a non-flash device for
which we use program as erase.
This commit reworks the algorithms, based on the fact that a block
device can erase or program as many units as needed in one go.
The "erased_set_get" test case deinits `FileSystemStore`, erases the
block device, and reinits `FileSystemStore`. This of course fails,
because `BlockDevice::erase()` removes all stored data including the
format of the `FileSystem` (middle layer), unless the particular type
of block device has a no-op erase implementation.
Note: Previously `HeapBlockDevice::erase()` was essentially a no-op
so this test case did not fail. We recently added the freeing of heap
memory and it uncovered the problem.
Mbed OS does not enable C++ exceptions, so we should call `new` with
`std::nothrow` which returns a C-style NULL pointer when allocation
fails to allow error handling.
For consistency of style within the same file, this commit also
replaces `malloc()` and `free()` to `new (std::nothrow)` and `delete`.
Update CMAKE_MODULE_PATH at once place.
Note, we update also CMAKE_MODULE_PATH in app.cmake. This is temporary until we get a proper way to include
Mbed Os (removing app.cmake need to be included by an application).
To avoid conflicts as we expose our CMake list files via CMAKE_MODULE_PATH. Some files already include it, this
aligns the rest of files.
I leave app.cmake as it is - it's user facing and it would be breaking change. We can clean this one for the next major version.
CMAKE_CURRENT_LIST_DIR behaves differently in functions. We store it in the CMakeLists itself, so anyone
calling a function would get the actual list dir where the scripts are.
To illustrate: if I call a function from src/CMakelists.txt, function located in src/scripts, `CMAKE_CURRENT_LIST_DIR` in the function would point
to the src/ folder but not to src/scripts.
All files within tools/cmake can now include within tools/cmake. We do not expose
internal folders like core/profiles/toolchains.
They should be included via toolchain file (mbed_toolchain in our case).
- list files included via module path
- <project-name>_SOURCE_DIR for sources that are out of the current processed CMake
- CMAKE_CURRENT_LIST_DIR for listfiles
mbed-nanostack should depend on mbed-802.15.4-rf to avoid a linker error
with an undefined reference to `NanostackRfPhy::get_default_instance()`.
The error occurs when `device_has: 802_15_4_PHY` is defined and the
consumer depends on mbed-nanostack in their CMakeLists.txt. Previously
we linked mbed-nanostack to mbed-802.15.4-rf, so mbed-802.15.4-rf's
usage requirements weren't forwarded to consumers who depended on
mbed-nanostack.
With the previous configuration, the consumer would have to depend on
mbed-802.15.4-rf directly to avoid an issue. This seems like a layering
violation: it appears that mbed-nanostack is "the API" and
mbed-802.15.4-rf is one of several possible implementations which are
selected based on configuration macros.
This commit changes the flow of dependencies so that mbed-nanostack ends
up with the correct symbol definitions.
At 9600 baud, a large part of the serial output of the crash reporting
example is missing on CI boards, causing the example test to fail. At
a higher serial speed (115200 baud), the entire output is intact.
This is in alignment with ARMmbed/mbed-os-example-crash-reporting#65.
Fixes#14535
Runtime code that analysed clock frequency to determine numerator and
denominator for conversion to standard 1MHz failed to handle the case
of either being 1 correctly.
Although it would spot other values that could be performed as shifts,
it failed to spot that 1 is "shift by 0", so would end up doing runtime
multiply and/or divide by 1. The runtime divide by 1 could be slow on a
Cortex-M0 device, increasing interrupt latency.
UART character loss on STM32F0 devices has been traced to this incorrect
code.
Correct the `exact_log2` routine so that `exact_log2(1)` returns 0 to
fix this.
Original code had a single special no-multiply-or-divide case for
hardware clock frequency being exactly 1MHz, as USTICKER is on STM32F0 -
this code lacks that but has a more general special case that covers all
shift-convertible frequencies like 500kHz or 8MHz, which should be
similar speed as shifts are cheap.
The repository mbed-os-example-nfc contains two examples: NFC_EEPROM
and NFC_SmartPoster. According to their respective `mbed_app.json`,
only NUCLEO_F401RE supports both examples, so we limit the compilation
test to this target only.
Compilation with an unsupported target fails (as expected) with Mbed
CLI 2 which enforces a check on a target's availability of the
required NFC controller. Mbed CLI 1 lacks such check and always
compiles.
FixesARMmbed/mbed-os-example-nfc#106
Martin Kojtal
Lingkai Dong
Anna Bridge
Robert Walton
Jaeden Amero
Chandran Praveen Babu (CYSC CSS ICW SW PSW)
jeromecoutant
Kevin Bracey
harmut01
Anish Kumar
Chun-Chieh Li