Fix bug where calling set_format in MBED (which calls serial_format) causes the CTRL register to become corrupt due to saving its initial value to a uint8_t when the register is 32 bit wide
Fix bug where calling set_format in MBED (which calls serial_format) causes the CTRL register to become corrupt due to saving its initial value to a uint8_t when the register is 32 bit wide
The HAL gpio_irq_api stores object IDs, which serve as a form of context
for the dispatch of the interrupt handler in the drivers level
InterruptIn Class. The way this is achieved is that the InterruptIn
Class casts its address to uint32_t, which is stored as the ID.
This results in compilation failure when the size of an object pointer
is greater than uint32_t, for example when building on a PC for unit
testing.
In order to allow Unit Testing of the InterruptIn Class, we replace the
use of uint32_t with uintptr_t (type capable of holding a pointer),
which allows portability and expresses intentions more clearly.
In aid of this latter goal, we also replace the use of the name "id"
with "context", to improve clarity - these are addresses of the context
related to that callback.
The HAL can_api stores an array of IDs in order to dispatch interrupts
to the correct CAN object. The drivers level CAN Class casts a pointer
to itself to an uint32_t, which is stored as the ID and then cast back
to a CAN * in order to call the correct handler. This results in
compilation failure when the size of an object pointer is greater than
uint32_t, for example when building on a PC for unit testing.
In order to allow Unit Testing of the CAN Class, we replace the use of
uint32_t with uintptr_t (type capable of holding a pointer), which
allows portability and expresses intentions more clearly. In aid of this
latter goal, we also replace the use of the name "id" with "context",
to improve clarity. These are addresses of the context related to that
callback.
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.
Renamed D0..D15 and A0..A5 to ARDUINO_UNO_D0 etc.
This allows user to use ARDUINO_UNO as the supported_form_factors in targets.json for MIMXRT1050_EVK.
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).
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.
- 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
This needs to be removed as there should not be a
name requirement for application CMake variable name.
Furthermore, in certain uses cases it prevents
successful builds for some Mbed targets. For instance
when building Greentea test applications for Mbed
targets that require post build operations as they do
not define APP_TARGET.
Update the BMCR0, BMCR1 registers to adjust the SEMC
re-order rules. This can improve the SDRAM stability
under multiple AXI masters system.
Signed-off-by: Gavin Liu <gang.liu@nxp.com>
Update the LUT to fix the winbond qspi flash erase issue.
Update the page program interface to fix the qspi flash program issue.
Signed-off-by: Tim Wang <tim.wang@nxp.com>
Change the lpspi default transfer delays to fix the data corruption
issue.
Add the loop and judgement to retry transfer when spi bus is busy.
Add the judgement statement to fix the hang issue.
Signed-off-by: TimWang <tim.wang@nxp.com>
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.
A CMake custom target, mbed-post-build, is added as a dependency of the
application CMake target if a Mbed target adds a CMake custom target
named mbed-post-build-bin. mbed-post-build-bin is added as a dependency
of mbed-post-build. mbed-post-build-bin depends on the application binary.
This is done so a CMake custom command that executes post-build can be added.
The Python scripts that implement the operations have been modified to add
CLI entry points so they can be called from CMake. Dependency on the old
tool has been removed on those scripts by passing them exactly what they
require instead of passing old tool Python objects. A consequence of that
was to slightly amend how the old tool calls some of those Python modules.
Support has only been added for Mbed targets that currently have a requirement
for post build operations. This includes: LPC1114, LPC1768, ARCH_PRO, LPC54114,
LPC546XX, FF_LPC546XX, CY8CKIT064B0S2_4343W, CYTFM_064B0S2_4343W, CYSBSYSKIT_01
The following targets are not supported as TFM support is not yet included:
ARM_MUSCA_B1, ARM_MUSCA_B1_NS, ARM_MUSCA_S1, ARM_MUSCA_S1_NS.
Refactor all NXP targets to be CMake build system targets. This removes
the need for checking MBED_TARGET_LABELS repeatedly and allows us to be
more flexible in the way we include MBED_TARGET source in the build.
A side effect of this is it will allow us to support custom targets
without breaking the build for 'standard' targets, as we use CMake's
standard mechanism for adding build rules to the build system, rather
than implementing our own layer of logic to exclude files not needed for
the target being built. Using this approach, if an MBED_TARGET is not
linked to using target_link_libraries its source files will not be
added to the build. This means custom target source can be added to the
user's application CMakeLists.txt without polluting the build system
when trying to compile for a standard MBED_TARGET.
The heap size was incorrectly calculated.
This fixes it by subtracting the Stack size, any memory chunks allocated
before the start of the application (for vectors and/or crash report), and
finally the size of the application from the total RAM size.
grumpyengineer
Yilin Sun
Hari Limaye
Lingkai Dong
Anna Bridge
s-bruce13
James Norton
Martin Kojtal
Harrison Mutai
George Psimenos
Arto Kinnunen
Hugues Kamba
Gavin Liu
Tim Wang