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.
The DEVICE_FOO macros are always defined (either 0 or 1).
This patch replaces any instances of a define check on a DEVICE_FOO
macro with value test instead.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
--legacyalign, --no_legacyalign are deprecated from ARMC6 compiler, in order to
remove deprecated flags all linker files (GCC and IAR as well to have uniformity)
should strictly align to 8-byte boundary
In current implementation `rtc_read` function returns number of elapsed us and `rtc_write` function sets RTC time to specified value in us.
Mbed HAL API expects that these functions operate on seconds.
Since lp ticker is also based on RTC provide mechanism to trace elapsed seconds without modifying RTC registers.
Three main issues:
1) The 0x13 special case section in write data in ncs36510_i2c.c didn't have a write++ command.
2) In the same write function, the WDAT8 command was put before the 0x13 section and this is not correct
3) Needed to add wait_us(0) before and after the register writes for apparent clock domain crossing delay times until registers are stable in HW
There were also a handful of other tweaks related to general code maintenance and moving some status register checks to the proper locations.
Add NOPs after deep sleep to prevent unexpected behavior. It appears
that the first one or two instructions after deep sleep do not get
executed properly.
Note - This is a temporary workaround. For a more robust solution
the NCS36510 needs to investigate the root cause of this issue.
fire_interrupt function should be used for events in the past. As we have now
64bit timestamp, we can figure out what is in the past, and ask a target to invoke
an interrupt immediately. The previous attemps in the target HAL tickers were not ideal, as it can wrap around easily (16 or 32 bit counters). This new
functionality should solve this problem.
set_interrupt for tickers in HAL code should not handle anything but the next match interrupt. If it was in the past is handled by the upper layer.
It is possible that we are setting next event to the close future, so once it is set it is already in the past. Therefore we add a check after set interrupt to verify it is in future.
If it is not, we fire interrupt immediately. This results in
two events - first one immediate, correct one. The second one might be scheduled in far future (almost entire ticker range),
that should be discarded.
The specification for the fire_interrupts are:
- should set pending bit for the ticker interrupt (as soon as possible),
the event we are scheduling is already in the past, and we do not want to skip
any events
- no arguments are provided, neither return value, not needed
- ticker should be initialized prior calling this function (no need to check if it is already initialized)
All our targets provide this new functionality, removing old misleading if (timestamp is in the past) checks.
Do not ticker read in ISR, use reminder to schedule the next interrupt, this should make ticker much faster.
read - disable Timer0 while reading it, if ISR is pending just reread the time again via read() function
These 2 improvements should decrease time spent when reading/scheduling ticker
events.
* Initialization clear interrupt status
* Remove state in management of interrupt
* Handle timestamp in the past
* Handle current seconds, even if out of the relative timestamp.
* Simplify interrupt handling logic.
There is an easy default implementation of spi_master_block_write that
just calls spi_master_write in a loop, so the default implementation
of spi_master_block_write has been added to all targets.
Revert HRM1017 file source deletion
Added in small comment next to additions
Added mapping to BTN-labelled switches
Added mapping to USER_BUTTON-labelled switches
Undo incorrect mapping to SWIO pin in NORDIC target