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.
Instead of user defined symbols in assembly files or C files,
use linker scripts to add heap and stack - this is inconsistent
with ARM std linker scripts
--legacyalign, --no_legacyalign are deprecated from ARMC6 compiler, in order to
remove deprecated flags all linker files should strictly align to 8-byte boundary
Decreased stack size from 24kB to 1kB (stack is used on boot-up/interrupt
handler). Increased heap size from 65kB to 89kB.
Change is related to issue https://github.com/ARMmbed/mbed-os/issues/7137
where UBLOX_EVK_ODIN_W2 runs out of heap on WLAN.
This commit completely rewrote flash_api.c in a few places so kicked out changes from Master and accepted the branch changes.
F429 + F439 : changes after code review
GetSector has been rewritten
- default value is the same as before patch
- system_stm32f4xx.c file is copied to family level with all other ST cube files
- specific clock configuration is now in a new file: system_clock.c
- nvic_addr.h file is now in TARGET_STM level, and can be used everywhere
For STM32 targets using a 32-bit timer for the microsecond ticker, the
driver did not properly handle timestamps that are in the past. It
would just blindly set the compare register to the requested timestamp,
resulting in the interrupt being serviced up to 4295 seconds late
(i.e. after the 32-bit timer counts all the way around to hit the
timestamp again).
This problem can easily be reproduced by creating a Timeout object
then calling the timeout's attach_us() member function to attach a
callback with a timeout of 0 us. The callback will not get called for
over 2147 seconds, and possibly up to 4295 seconds late if no other
microsecond ticker events are getting scheduled in the meantime.
Now, after the compare register has been set, the timestamp is checked
against the current time to see if the timestamp is in the past, and
if so, the compare event is manually set.
NOTE: By checking if the timestamp is in the past after configuring the
capture register, we ensure proper handling in the case where the timer
updates past the timestamp while setting the capture register.
Check in flash algos for the K64F, KL46Z, F429, F439 and Odin board
and enable these features accordingly in targets.json. This
implementation uses flash algo blob that are generated via scripts.
The K64F and KL46Z were generated directly from packs, while the
KL46Z, F429, F439 and odin were generated from code checked into
the FlashAlgo repo.
The address of the vector table is hardcoded to the start of flash in
many, if not all, ST targets. This causes a crash in applications that
are using a bootloader. This patch updates the boards STM32F429xI,
STM32F439xI and Odin so they properly handle updating the VTOR with
a bootloader.
Kevin Bracey
jeromecoutant
Deepika
Przemyslaw Stekiel
Senthil Ramakrishnan
Cruz Monrreal
bcostm
Mika Leppänen
Jimmy Brisson
adustm
Sam Grove
Andreas Larsson
Bradley Scott
Bartek Szatkowski
0x6d61726b
0xc0170
Christopher Haster
Russ Butler
Russ Butler