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
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
The -mcpu=cortex-a9 flag conflicts with the march=armv7-a flag.
Opted to keep mcpu=cortex-a9 as it is more specific and
allows GCC to perform better optimization.
The compiler is also changed to use soft-float ABI as it
was necessary to successfully build. Without it the application
appears to be built with soft-float ABI and it conflicts with
the previous setting which was built with hard-float ABI.
This may be related to: https://gitlab.kitware.com/cmake/cmake/-/issues/21173
Binaries generated for Cortex-M33 targets (e.g. Musca S1/B1) using
the Arm toolchain + CMake is unable to run, unless we instruct the
linker to not use floating points.
Note: This is a temporary workaround, because
* Ideally, the Arm linker should be able to auto detect the
architecture support from the input object files, but it's not
always the case. We already have a similar workaround for Cortex-M4.
* The full option to use should be `--cpu=Cortex-M33.no_dsp.no_fp`
but `no_dsp` currently conflicts with CMake's compilation tests
(no option to disable DSP in the test objects before linking).
- No longer need to create mbed_os.lib and soft link to mbed-os as new
--mbed-os-path command-line removes such dependency and creates mbed_build.cmake
when passing mbed-os path with that command line argument.
Fixes: #14153
The target CYTFM_064B0S2_4343W is signed using `cysecuretools` which
depends on `imgtool` managed by `pip`. However, Arm Musca targets
requires a modified/wrapped version of the image tool copied from
trusted-firmware-m + MCUboot.
To avoid conflicts in the version of `imgtool` used, we should only
add the copied version of `imgtool` to python's system path for
Musca targets instead of doing it globally for all targets.
In targets.json, ARM_MUSCA_B1 and ARM_MUSCA_S1 have alias target
names suffixed with `_NS`. They are identical to targets without
`_NS` and exist purely for compatibility with the old naming
convention we had. The CI builds them as separate targets and uses
extra resources.
As we are upgrading Musca targets to TF-M v1.2, it's time to clean
up the aliases.
The script changes are required with respect to TF-M v1.2
integration for this target. The imgtool.py is been replaced with
`wrapper.py` which uses click command to run the signing algorithm.
The version `-v` and dependencies `-d` have been updated to resolve
upgrade issues from TF-M v1.1 --> v1.2
The script changes are required with respect to TF-M v1.2
integration for this target. The imgtool.py is been replaced with
`wrapper.py` which uses click command to run the signing algorithm.
The version `-v` and dependencies `-d` have been updated to resolve
upgrade issues from TF-M v1.1 --> v1.2
These files have been imported/copied from:
* ARMmbed/trusted-firmware-m
* ARMmbed/tf-m-tests
These are generic files, which are required for TF-M v1.2 integration
with Mbed OS for PSA_V8M and PSA_DUAL_CORE targets.
The GCC flag to specify the floating-point hardware (`mfpu`) does not accept
the value `none`. The default value is `auto` which causes the compiler to
select the floating-point and Advanced SIMD instructions based on the
settings of -mcpu and -march. The extension option `+nofp` has been added
to disable floating point instructions.
There should not be a reference to APP_TARGET in Mbed OS as end-users
may decide to use a different name for the CMake variable to store their
application name.
The CMake custom target must be unique to avoid more than one
Mbed target adding the same. Only the CMake custom command added for the
Mbed target being built is run as the custom CMake target now includes
the Mbed target name.
We need to generate a "response file" to pass to the C preprocessor
when we preprocess the linker script, because of path length limitations
on Windows. We set the response file and bind the path to a global
property. The MBED_TARGET being built queries this global property when
it sets the linker script.
We must set this global property before the targets subdirectory is
added to the project. This is required because the MBED_TARGET depends
on the response file. If the path to the response file is not defined
when the target requests it the config definitions will not be passed
to CPP.
Martin Kojtal
Jaeden Amero
Lingkai Dong
jeromecoutant
Anna Bridge
Saheer Babu
Hugues Kamba
Rajkumar Kanagaraj
Ladislas de Toldi
Vikas Katariya
Robert Walton