ARM Compiler 6.13 testing revealed linker errors pointing out
conflicting use of `__user_setup_stackheap` and
`__user_initial_stackheap` in some targets. Remove the unwanted
`__user_initial_stackheap` from the targets - the setup is
centralised in the common platform code.
Looking into this, a number of other issues were highlighted
* Almost all targets had `__initial_sp` hardcoded in assembler,
rather than getting it from the scatter file. This was behind
issue #11313. Fix this generally.
* A few targets' `__initial_sp` values did not match the scatter
file layout, in some cases meaning they were overlapping heap
space. They now all use the area reserved in the scatter file.
If any problems are seen, then there is an error in the
scatter file.
* A number of targets were reserving unneeded space for heap and
stack in their startup assembler, on top of the space reserved in
the scatter file, so wasting a few K. A couple were using that
space for the stack, rather than the space in the scatter file.
To clarify expected behaviour:
* Each scatter file contains empty regions `ARM_LIB_HEAP` and
`ARM_LIB_STACK` to reserve space. `ARM_LIB_STACK` is sized
by the macro `MBED_BOOT_STACK_SIZE`, which is set by the tools.
`ARM_LIB_HEAP` is generally the space left over after static
RAM and stack.
* The address of the end of `ARM_LIB_STACK` is written into the
vector table and on reset the CPU sets MSP to that address.
* The common platform code in Mbed OS provides `__user_setup_stackheap`
for the ARM library. The ARM library calls this during startup, and
it calls `__mbed_user_setup_stackheap`.
* The default weak definition of `__mbed_user_setup_stackheap` does not
modify SP, so we remain on the boot stack, and the heap is set to
the region described by `ARM_LIB_HEAP`. If `ARM_LIB_HEAP` doesn't
exist, then the heap is the space from the end of the used data in
`RW_IRAM1` to the start of `ARM_LIB_STACK`.
* Targets can override `__mbed_user_setup_stackheap` if they want.
Currently only Renesas (ARMv7-A class) devices do.
* If microlib is in use, then it doesn't call `__user_setup_stackheap`.
Instead it just finds and uses `ARM_LIB_STACK` and `ARM_LIB_HEAP`
itself.
- Fixed miscalculation in SPI frequency setup (divider value).
- Added possibility to set up SCK line as NC (usable when SPI peripheral
is used to handle non-SPI protocols.
- Fixed handlingh of 16-bit (and other >8 bit) transfers.
(cherry picked from commit 7d391f257b4ff6cdd7b43eeaa4894f8ce6d2cf8e)
Fixed HAL API implementation for InterruptIn:
- Interrupt was not enabled by default after configuration as it should be.
- Interrupt-to-object linking was not handled properly.
The use of `gpio_irq_event` & `gpio_irq_handler` in `gpio_irq_s` creates
a circular dependency.
hal/gpio_irq_api.h needs
targets/TARGET_Cypress/TARGET_PSOC6_FUTURE/TARGET_CY8C63XX/device.h, that needs
targets/TARGET_Cypress/TARGET_PSOC6_FUTURE/objects.h, that again needs
hal/gpio_irq_api.h, before the types are defined.
Remove `#include "gpio_irq_api.h"` directive from objects.h and change
the types of `gpio_irq_s` members.
Deprecate wait() in favour of acquire(), try_acquire(),
try_acquire_for() and try_acquire_until().
Brings Semaphore more into line with CMSIS-RTOS 2 (which uses "acquire"),
itself (as it has "release"), and other classes having "try", "try for"
and "try until".
Also steps away from vague "wait" term - the primary operation here is
to acquire the semaphore, and this will of course sleep.
due to partial implementation. Having FUTURE_SEQUANA_M0 and
FUTURE_SEQUANA PSA targets is misleading.
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
PDL Flash API requires that the data buffer is 32-bit aligned, otherwise
programming can hung. Buffer declared as uint8_t array is not always
properly aligned, e.g. with gcc 6 when -Os option is used.
This change moves all PDL drivers into common source and include
directories to alleviate issue with Windows version of GNU Make 4.x
maximum command line length limit.
Fixed interrupt vector settings on M0 core. Wrong vector settings prevented
LP_TICKER from working, resulting in deep sleep tests failing on M0
or PSA variant.
This data, placed at physically not existing addresses (0x9xxxxxxx) was used
only by PSoC Programmer and KitProg2 and is no longer needed, but was causing
issues with standard hex file processing tools like srecord (srec_cat).
Page size in all PSOC6 boards is 512 bytes. This is very problematic in
all storage applications. This change reduces the page size (in flash_api's
flash_program_page API) to 32 by reading the original page, modifying it
with programmed data and programming it back. The number 32 for page size
conforms to the number of times (16) this action can be done.
Fix port_write API to correctly shift the passed value.
This allows the reference application provided in PortOut docs
to work corectly with arbitrary LED_MASK.
https://os.mbed.com/docs/mbed-os/v5.11/apis/portout.html
The fix applies to both PSOC6 and PSOC6_FUTURE HAL implementations.
Enabled tickless mode for Sequana PSA M0 core code to allow it to enter
deep sleep mode. This fixes issue #9094 where tests were failing due to
M0 core not entering deep sleep mode, blocking the whole chip.
Fixed incorrect resource management on M0 core, which crashed tickless
mode.
1. Removed random i/o glitches occurring during device reconfiguration
2. Fixed hazardous reads occurring at the end of transfer resulting
in incorrect values being received
3. Added spi_free() function
4. Replaced default M0 image with a one ignoring i/o reservation. This is
a workaround for missing proper destructors in Mbed drivers and BlockDevice
tests failing on repeated initialization
Fixes issue #9620.
The targets/TARGET_Cypress/TARGET_PSOC6 is dedicated to the mbed-os HAL
and PSoC 6 MCU targets developed by Cypress Semiconductor. Move the
existing port developed by Future Electronics to TARGET_PSOC_FUTURE
and update the labels in targets.json appropriately.