References to time should do so using std::chrono. We reworked tests in
connectivity and drivers to use std::chrono and new APIs in order to
remove deprecation warnings resulting from deprecated API calls.
This required addition of a macro for test assertions using std::chrono
values.
As host test "timing_drift_auto" expects time values represented as an
integral number of microseconds, we explicitly provide this in place
using "microseconds{TICKER_TIME}.count()" in the relevant ticker tests.
We recognise this is ugly, but thought it best to descriptively convert
from std::chrono to the host test's required representation.
Co-authored-by: Hari Limaye <hari.limaye@arm.com>
We failed to set `LoRaMac_stub::mlme_ind_ptr` to a valid pointer. When
we tried to dereference it in `LoRaWANStack::process_reception` we hit a
SEGFAULT.
This test was relying on the state of `LoRaMac_stub::bool_true_counter`
to be set to 1 from a previous test. When the test was ran in isolation
the `LoRaWANStack::rx_timeout_interrupt_handler` callback would fail
because we weren't returning true from the stub implementation of
`LoRaMac::nwk_joined`. Due to this
`LoRaWANStack::post_process_tx_no_reception` was never called. This
caused the LoRaWANStack object to think the "tx_metadata" was "stale"
(i.e the data hadn't changed since any previous read). So, when we
attempted to call `LoRaWANStack::acquire_tx_metadata` it returned
`LORAWAN_STATUS_METADATA_NOT_AVAILABLE` as it thought we had no new
metadata to report, causing the test assertion to fail.
We had commented out a line where we reset LoRaPHY_stub::uint16_value to
0. This was causing an invalid array access in
LoRaMac::handle_data_frame, when trying to extract the
_mps_indication.channel from list of channel_params_t returned by
lora_phy->get_phy_channels.
Some tests in athandlertest.cpp relied on the state of stubs set in
previous tests. This caused test failures if the tests cases were ran in
isolation. Remove the interdependencies between tests by setting stub
values in the tests that rely on them.
Previously a test executable was recognised as a single test by CTest.
However, test executables usually contain multiple test cases, the
results of the test cases should be individually reported. With our
previous setup we could miss test case failures that didn't cause the
executable to return an error code.
This commit uses gtest_discover_test to discover all test cases in a
test executable. This enables CTest to match test passes and failures
from the googletest binary output.
The CircularBuffer doesn't allow pushing zero elements; you must push at
least one. Update the CircularBuffer unit test to avoid invalid use of
the CircularBuffer.
We previously made up an invalid message type, which was roughly
`MCPS_MULTICAST | 0x40`. This causes an MBED_ASSERT failure in the
handle_rx function, as it uses an assert to validate the message type
passed to it (in convert_to_msg_flag()). Use the valid message type
MCPS_MULTICAST instead in the handle_rx unit test.
tz_context.c should be compiled only for secure world,
definition of API's in tz_context.h should be part of secure
binary/bootloader when building mbed-os as non-secure
(Cherry picked from d0a43b8af0)
(cherry picked from commit fb354752eb)
mbed OS used older RTX4 version and with osThreadDef accepting only 3
parameters, to preserve compatibility we hardcode the 'instances'
parameter to 1.
(cherry picked from commit 428acae1b2ac15c3ad523e8d40755a9301220822)
(cherry picked from commit 4360b7bbf8)
The variable for archiver is automatically set by CMake. There is
no need to explicitly set it, unless a project really needs to
override the default archiver.
CMake versions 3.20 and below always add compiler and linker flags
based on `CMAKE_SYSTEM_PROCESSOR`, for example `--cpu=Cortex-M33`.
This sometimes overrides flags we set in tools/cmake/cores/*.cmake
and results in link failure or unbootable binaries. To workaround
this, we added more linker flags to "counter" what CMake automatically
adds.
From CMake 3.21 onwards, CMake by default does not add flags to
armclang anymore, and it fully relies on projects to set all flags.
In this case we do not need to set `CMAKE_SYSTEM_PROCESSOR` or use
workarounds anymore. We still turn on workarounds when an older
version of CMake (3.19 and 3.20) is used, but in the future we might
require users to have at least CMake 3.21.
As we're moving away from the use of CMAKE_SYSTEM_PROCESSOR, use
MBED_CPU_CORE instead. They differ in cases, but both GCC and Arm
toolchains support case-insensitive CPU names.
On a target that doesn't support Firmware Update, compilation still works, and any attempt to call the Firmware Update API returns a runtime error which is good enough.
Add extern "C" to the equeue_stub declaration to avoid an error when a C
file implements the equeue_stub symbol (as we do in equeue_stub.c).
Undefined symbols for architecture x86_64:
"_equeue_stub", referenced from:
Test_LoRaWANTimer_start_Test::TestBody() in Test_LoRaWANTimer.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The CMake macro `mbed_post_build_psoc6_merge_hex()` takes the name of
a Cypress target and an optional Cortex-M0 hex image as arguments. The
proper way to define and parse optional arguments of a function or
macro is `cmake_parse_arguments()`, which allows the caller to
indicate what they are passing rather than rely on an argument's
relative position within `${ARGN}` which is not rigorous.
Also, avoid duplicating the common part of the post build command
when the optional argument is passed/not passed.
When building greentea tests, each test is an executable with its
own output binary path. This is also the case when a user project
produces multiple executables. But the current implementation of
post-build operations always assumes there's only one executable,
at the root of the build directory.
The post-build command depends on Mbed target, and it always takes
the the executable we build as an input file. To achieve this, we
let each Mbed target (that has a post-build command) define a function
function(mbed_post_build_function target)
which takes a CMake executable target as an argument from which it can
get its binary path using generator expressions. It generates and adds
to the passed executable target a post-build custom command.
Notes:
* The function name needs to be exact, because CMake only supports
literal function calls - CMake can't dereference a function name from
a variable. To avoid multiple definitions of this function, each Mbed
target needs to guard it with a macro to check if the user is
building this Mbed target.
* `mbed_post_build_function()` is a function, but it is usually
defined by another macro rather than a parent function, because
nesting functions would make many variables inaccessible inside the
innermost `mbed_post_build_function()`.
* There's no more need to force regenerate images. Previously, post-
build commands were custom *targets* which always got to run, so we
force regenerated images on every build to avoid patching an image
that's already been patched once on previous build. Now post-build
commands are custom *commands* of the same executable target, and they
are only run if the executable target itself is rebuilt.
Use the `--coverage` option instead of manually linking to gcov, as some
host platforms (like macOS, FreeBSD) don't have gcov by default and use
an llvm equivalent instead.
The 'post build' functions are made visible by adding the mbed-os
subdirectory. This is not ideal as any components in mbed-os wishing to
call the functions must be added after the functions are defined. To
improve modularity move these functions to a separate CMake script.
We include the post build CMake script in app.cmake for now so we don't
break user's projects.
This helps to allow installation of Mbed OS's Python requirements, when
CMake is used, into the same Python environment as mbed-os-tools. The
versions specified here are aligned with mbed-os-tools;
tools/cmake/requirements.txt depends on the same version of prettytable
as mbed-os-tools's requirements.txt.
Mbed CLI 1 parses the base requirements.txt and attempts to
automatically install missing python libraries for you. Unfortunately,
it's requirements parser is not as capable as the one shipping with pip.
In particular, we are unable to express different version of libraries
conditional on the version of Python being used.
---
[mbed] ERROR: Unknown Error: Unsupported environment marker: python_version < '3.6'
Remove the direct dependency on prettytable from requirements.txt, as
mbed-os-tools depends on prettytable and we can pick up the dependency
(as properly expressed conditionally on the Python version) from there,
without having to use the limited requirements parser in Mbed CLI 1.
Martin Kojtal
harmut01
Charles
Jaeden Amero
Robert Walton
Bartek Szatkowski
Deepika
Lingkai Dong
jeromecoutant
Chun-Chieh Li