µVision 5.28a now has options for gnu++14, c++14 and c++17, so we can
use them rather than falling back to c++14 or gnu++11.
This does mean that an export of current master, which uses gnu++14,
will now require version 5.28a. I have not tested what happens if
5.27 is given a project file with these new option numbers.
However, export of current master is broken for 5.27 anyway, as the
fallback to gnu++11 means it fails to compile the C++14 constructs
now in the codebase.
Fixes#11217, as long as users update µVision too.
* Modify compilation API to provide a list of paths to exclude from the build.
* `_exclude_files_from_build` becomes a static method
* Replace ternary expression with simple `if/else` statement
* Make unit test case for dirs exclusion independent of system files
* Fix rtos include path in NRFCordioHCIDriver
* Flatten USB driver directory structure
* Add missing include for us_ticker
* Add more missing includes for us_ticker
* Fix mbed_hal_fpga_ci_test_shield/uart test
* Fix bare-metal build
* Fix Watchdog UNITTEST
* Fix Mbed OS 2 build for Public/Internal headers relocating
The contents of the usb directory were moved to appropriate locations and the usb directory removed.
* Public USB headers moved under drivers/
* Internal USB headers moved under drivers/internal/
* USB Source code moved under drivers/source/usb/
* Moved usb/device/hal/ under hal/usb/
* Moved usb/device/USBPhy/ under hal/usb/
* Merged usb/device/targets/ into targets/
* Separated public and private USB API documentation under Doxygen groups drivers-public-api and drivers-internal-api.
Separate drivers, events, and rtos internal APIs from public APIs.
* Move source files to source subdirs
* Move internal headers to internal subdirs
* Add Doxygen comments for documenting internal and public APIs
* Remove source code from header files in order to remove include pre-processor directives
that included header files not directly used by said header files
* Explicitly include header files instead of implicit inclusions via third-party header files.
Release Notes
This will break user code that was using an internal API as the internal header files have been moved.
This will only break if the user was including the header file using a namespace (i.e #include "foo/bar.h" instead of #include "bar.h"
* Fixed wrapper functions for IAR
* Fixed and renamed profile to minimal-printf.json
* Moved minimal-printf under platform
* Removed minimal-printf/mbed_lib.json
* Modified exporter template to work with partial profile
* Prevented optimization of printf to avoid compiler function substitution
This brings massive ROM savings, and allows to use debug builds
also with larger applications (for. ex. Mesh stack).
Diff. for mbed-cloud-client-example with Wi-Sun stack.
Total Static RAM memory (data + bss): 85120(-216) bytes
Total Flash memory (text + data): 592668(-329296) bytes
* Adjust definition to make the default constructor `constexpr`.
This permits use in classes that want lazy initialization and their
own `constexpr` constructor, such as `mstd::mutex`.
* Add `get_no_init()` method to allow an explicit optimisation for
paths that know they won be the first call (such as
`mstd::mutex::unlock`).
* Add `destroy()` method to permit destruction of the contained object.
(`SingletonPtr`'s destructor does not call its destructor - a cheat
to omit destructors of static objects). Needed if using in a class
that needs proper destruction.
Do not specify the debug level for develop and release profiles. Instead
rely on the compiler to choose sensible default (-g2). Note that -g1 is
minimal debugging information and does not include structure definitions
which quite heavily reduces debugging experience.
For develop and release profiles this results in elf file containing
structure definitions. This does not impact debug profile as it already
did use -g3 which is the highest debug level.
Compatible debuggers (eg. gdb, SEGGER Ozone) can use the extra information
to provide better debugging experience. For example, when compiled .elf is
loaded in gdb, this change makes it trivial to access internal RTX data.
Without this change on develop profile:
(gdb) print osRtxInfo.thread.run
'osRtxInfo' has unknown type; cast it to its declared type
With this change on develop profile:
(gdb) print osRtxInfo.thread.run
$1 = {curr = 0x20014F04, next = 0x20014F04}
VSCode exporter was generating a launch config that contained absolute paths to the
compiler executables. It makes more sense to use the executables that are
installed into the system PATH.
When packing data into multiple regions using the `.ANY` directive,
the linker can accidentally overfill an area.
This doesn't normally happen because it defaults to
`--any_placement=worst_fit`, which puts data in the region with
most space.
When we prioritise regions with `.ANY1`/`.ANY2`, it may totally fill
an area, then fail to leave enough space for linker-generated veneers.
We've just seen this error with the new K64F linker map.
Adding `--any-contingency` makes it lower priority when a region is
98% full, avoiding this error.
The option should not have any effect on targets with scatter files
without prioritised `.ANY` directives.
Due to some historical reasons ARMC 5 compiler behaves very
differently compared to others (GCC, IAR, ARM C 6) as it optimizes
performance rather than size (like the others).
All compilers should behave the same way with the same profile,
thus ARM C 5 should also drive towards size (space).
Lots of target code, STM in particular, uses the `register` keyword, so
it'll take a little while to clean up. In the interim, some builds are
producing a lot of warnings. Suppress the warning for now, as `register`
remains legal C++14 and C11, despite C++14 deprecating it.
C++17 removes `register`, so code will need to be cleaned before any
further C++ version update.
Clang warns about reserved user-defined literals by default. This
warning is not terribly helpful; compilers aren't normally in the
habit of warning about use of reserved identifiers. It can interfere
with, for example, deliberate emulation of a future standard
language feature.
The warning was promoted to an error in an mbed client build, due to a
non-C++11 "%s"name occurring in a macro. But the macro itself was never
invoked, so the misinterpretation as C++11 caused no problems other than
this warning. Killing the warning will let that code build on ARMC6.
The code already built on GCC and IAR.
If that macro ever was used, then a separate error about operator ""
name not being defined would be generated, on all 3 toolchains.
This is limited to ARMC6 because as of µVision V5.27 you can't set C++11
for ARMC5.
Also current µVision does not support gnu++14. We should be able to get
is as `<default>`, as it is the default for ARM Compiler 6.10-6.12,
but this option does not work as documented and actually requests
gnu++89 explicitly. So gnu++14 is mapped to gnu++11.
Musca-A1 is a Cortex-M33 based target with security extension enabled.
- ARM_MUSCA_A1 is the non-secure target running mbed-os.
- ARM_MUSCA_A1_S is the secure target running TF-M.
- TF-M sources were imported and patched in previous commits.
- TF-M secure bootloader (McuBoot) for MUSCA_A1 is submitted by a pre-built binary.
- A post-build hook concatenates The secure and non-secure binaries,
signs it and then concatenates the bootloader with the signed binary.
due to partial implementation. Having FUTURE_SEQUANA_M0 and
FUTURE_SEQUANA PSA targets is misleading.
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
Change the heuristic for selection of CMSE in the tools python, so that
a non-TrustZone ARMv8 build can happen.
Ideally we would have more direct flagging in the targets, but this
refines the heuristic so the necessary behaviour can be easily
achieved.
* DOMAIN_NS=1 is based purely on the `-NS` suffix on the core name.
* Enabling CMSE in the compiler and outputting a secure import library
is now enabled when the core doesn't have an `-NS` suffix by either
the target label `TFM` being present or the flag `trustzone` being set.
This covers the existing ARMv8-M behaviour - TF-M builds have the TFM
label, as per its documentation; M2351 secure builds have no explicit
flagging, so we ensure that the M2351_NS target has the trustzone flag
set, and the out-of-tree secure target inherits that.
PSA code generation will be called automatically upon mbed invocation.
The autogenerated files will be created under <mbed-os-root>/PSA_AUTOGEN directory.
Unify TF-M and Mbed-SPM code generators:
- Unify SPM initialization logic:
- All partitions are registered at once
- Test partitions are guarded by #ifndef
- Introduce single template list
- Beatify template files and add "Autogen-do not modify" notice
Prepare for integration with mbed-os build system:
- Generate all the files in a single place
Simplify tools/psa/release.py script
Anna Bridge
Olli-Pekka Puolitaival
Kevin Bracey
Evelyne Donnaes
Chris Snow
Martin Kojtal
cyliangtw
Hugues Kamba
George Psimenos
Teemu Takaluoma
Seppo Takalo
Vladislav Talanov
Tomasz Moń
Lin Gao
Volodymyr Medvid
Mark Edgeworth
Arto Kinnunen
itziar
d-kato
Devaraj Ranganna
Alexandre Bourdiol
Janne Kiiskila
Qinghao Shi
Alexander Zilberkant
Michael Schwarcz
jeromecoutant
Brian Daniels
Alexander Zilberkant
Oren Cohen
Oren Cohen