`HAL_SPI_Receive_IT` HAL function causes dummy reads in 3-wire mode,
that causes data corruption in RX FIFO/register. It isn't possible
to fix it without signification refactoring, but we may prevent data
corruption with the following fixes:
- RX buffer/register cleanup after asynchronous transfer in 3-wire mode
- Explicit RX buffer/register cleanup after SPI initialization
(for cases if we re-create SPI object).
All STM32 families except STM32H7 has the following 3-wire SPI peculiarity in master receive mode:
SPI continuously generates clock signal till it's disabled by a software. It causes that a software
must disable SPI in time. Otherwise, "dummy" reads will be generated.
Current STM32 synchronous SPI 3-wire implementation relies on HAL library functions HAL_SPI_Receive/HAL_SPI_Transmit.
It performs some SPI state checks to detect errors, but unfortunately it isn't fast enough to disable SPI in time.
Additionally, a multithreading environment or interrupt events may cause extra delays.
This commit contains the custom transmit/receive function for SPI 3-wire mode. It uses critical sections to
prevents accidental interrupt event delays, disables SPI after each frame receiving and disables SPI during
frame generation. It adds some delay between SPI frames (~700 ns), but gives reliable 3-wire SPI communications.
- move a code that waits readable SPI state from `spi_master_write`
function to inline functions `msp_writable` and `msp_wait_writable`
- move a code that waits writeable SPI state from `spi_master_write`
function to inline functions `msp_readable` and `msp_wait_readable`
- move a code that writes data to SPI from `spi_master_write`
function to inline function `msp_write_data`
- move a code that reads data from SPI from `spi_master_write`
function to inline function `msp_read_data`
This commit enables the Overriding of HAL callbacks and IRQHandler
in stm32xx_emac.cpp. Hence the user can have their own
implementations of callbacks and IRQHandler functions.
Signed-off-by: Kather Rafi Ibrahim <katherrafi.i@hcl.com>
As per STM32H7-series reference manuals:
"Up to 64 filter elements can be configured for 29-bit extended IDs."
This commit fixes a bug which prevented receiving CAN-messages
with extended IDs.
We weren't setting the "supported_application_profiles" correctly for
some baremetal supported targets. This didn't cause build failures with
mbed-cli 1 as it just seems to ignore this config parameter. In our CMake
build system we have added a hard dependency on the
supported_application_profiles; we fail the build if the profile we're
trying to build isn't in the list.
We were previously relying on the global MBED_PATH variable to provide
the root for the include path to the post build hooks. We can't
guarantee that MBED_PATH will be set by any application building us, so
use CMAKE_MODULE_PATH (which we always set) like we do for the other
post-build hooks.
This commit adds internal pullup on DP line for usb enumeration
in nucleo_l152re platform. This platform as such does not have
usb connector (device).
This has been tested with example in https://github.com/ARMmbed/
mbed-os/blob/master/drivers/usb/include/usb/USBMouse.h#L58-L76
and mbed_app.json file
"target_overrides": {
"*": {
"platform.stdio-baud-rate": 115200,
"platform.all-stats-enabled": true,
"mbed-trace.enable": "0"
},
"NUCLEO_L152RE": {
"target.device_has_add": ["USBDEVICE"]
}
}
}
Signed-off-by: Krishna Mohan Dani <krishnamohan.d@hcl.com>
1. Change from single image boot to multiple image boot
2. SDH is configured to Secure for placing update firmware. It becomes inaccessible to Mbed.
3. Post-build script supports both multiple image boot and single image boot
4. Update readme to reflect above change
5. Increase forced_reset_timeout due to longer booting time for Greentea test
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.