Today no way to identify device has LED and BUTTON at CMake configuration
time as those macros are "#define" in the "pin_names" header file of
the particular target but the problem is pin_names generic greentea
test skip or includes the test based on defines LEDx, BUTTIONx,
hence introducing the LED and BUTTON config which is added under
"device_has_add" of LED and BUTTON supported target.
CLI1 and CLI2 generate DEVICE_LED (all LED define guard in this
in pin_names.h) and DEVICE_BUTTON (all the button define guard with this
in pin_names.h) macros which can be used in pin_name generic greentea test CMake.
1. In TF-M, fix NSPE interrupt-disabled NSC call broken. Check:
https://developer.trustedfirmware.org/T966
2. In TF-M, enable mcuboot log enabled forcibly. This is to help check firmware update process.
3. Update readme and script
Import the latest partition headers from upstream. We no longer need to
patch the headers to define the BL2 macro as we now define it in the
scatter files for the MUSCA targets.
We worked around an issue with mbed-cli1 not recognising the BL2 macro
from targets.json by adding patched versions of region_defs.h and
flash_layout.h for ARM_MUSCA targets. In the patched headers we defined
the BL2 macro to ensure it can be picked up by the ARM scatter files
that include the headers.
The current solution is not robust, because it means that the
aforementioned headers easily become out of date. A workaround of
defining the macros in the scatter files which need them was suggested
in https://github.com/ARMmbed/mbed-os/issues/14762
This commit applies the suggested changes to the ARM_MUSCA scatter
files.
The directory structure upstream has changed. Now ARM_MUSCA board
support has been moved under an "arm" subdirectory. Update targets.json
with the new locations.
tfm_ns_interface.c is intended to be overriden by clients to support
different targets. We copy this file from upstream into the mbed-os
platform library. We also have a specific "strong" overridden version
for the NU_M2354 target, which is located in its target library.
Previously the implementations in the platform library were decorated
with __attribute__(weak), and we provided a strong definition for the
NU_M2354 target. This worked fine because of weak linking, the linker
will pick the first "strong" definition and use that, avoiding any ODR
violations. However, upstream have removed __attribute__(weak) from the
function definitions, which caused multiply defined symbol errors when
trying to build the NU_M2354 target.
To work around the above issue, we remove the common definition in the
platform library; instead we copy the file to the Musca B1 and Musca S1
target libaries. This means the appropriate tfm_ns_interface.c is only
included in the build when compiling for the specific target which uses
it.
QSPIF was disabled on CYW9P62S1_43012EVB_01 because its S25FS512S
flash chip has multiple configurations but our SFDP parser did not
support this scenario. Now having added support for this, we can
enable QSPIF (the component label for QSPIFBlockDevice) and QSPI
(the label for Quad-SPI communication).
Change MCUboot image versioning to meet requirements below:
1. Major.Minor.Revision must be non-decremental when used to derive security counter (-s 'auto').
2. Make Major.Minor.Revision+Build incremental to identify the firmware itself through psa_fwu_query().
3. Get around MCUboot failure with TF-M underestimated MAX_BOOT_RECORD_SZ
Import mcu partition header (renamed to partition_M2354_im.h) for resolving peripheral base with security.
Though Mbed is non-secure only and needn't secure peripheral base, some BSP driver code still rely on it.
`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>
Rajkumar Kanagaraj
Chun-Chieh Li
Robert Walton
Jaeden Amero
Lingkai Dong
Jerome Coutant
Martin Kojtal
Charles
Konstantin Kochin
Lukas Karel
Kather Rafi Ibrahim
cyliangtw