The heap size was incorrectly calculated.
This fixes it by subtracting the Stack size, any memory chunks allocated
before the start of the application (for vectors and/or crash report), and
finally the size of the application from the total RAM size.
Add license identifier to files which Arm owns the copyright to,
and contain either BSD-3 or Apache-2.0 licenses. This is to address
license errors raised by scancode analysis.
Scancode found missing license notices in our source files. This commit
addresses those issues by adding an Apache-2.0 notice to source files
highlighted.
Workaround a bug where the boot stack size configuration option is not
passed on to armlink, the Arm Compiler's linker. Prefer
MBED_CONF_TARGET_BOOT_STACK_SIZE if present, as this is what the
configuration system should provide. Fall back to MBED_BOOT_STACK_SIZE
if MBED_CONF_TARGET_BOOT_STACK_SIZE is not defined, as in the case of
buggy tools. If both MBED_CONF_TARGET_BOOT_STACK_SIZE and
MBED_BOOT_STACK_SIZE are not defined, then we fall back to a hard-coded
value provided by the linkerscript. See
https://github.com/ARMmbed/mbed-os/issues/13474 for more information.
To allow overriding of the boot stack size from the Mbed configuration
system, consistently use MBED_CONF_TARGET_BOOT_STACK_SIZE rather than
MBED_BOOT_STACK_SIZE.
Fixes#10319
* Update scatter file for the ARM toolchain to use 2 region memory model.
The scatter file changes affect the following boards:
* LPC1768, ARCH_PRO, UBLOX_C027, XBED_LPC1768 (LPC1768.sct)
* Remove the TOOLCHAIN_ARM_MICRO directory.
* Remove release_version as not necessary and as the target can also run
Mbed OS 6.
* Remove uARM toolchain in the list of supported toolchains for the target.
* Indicate that the target supports the small ARM toolchain C library.
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 (GCC and IAR as well to have uniformity)
should strictly align to 8-byte boundary
* Add source address word alignment check
* malloc and memcpy are called only if data is unaligned
* malloc size is now copySize (program page size), rather than whole buffer to be written
This patch fix flash write issue when program size is more than page size (= 1024 bytes). See detail - https://github.com/ARMmbed/mbed-os/issues/6165
Source data always use aligned data in heap memory.
From RM:
32.3.2.6 Interrupts during IAP
The on-chip flash memory is not accessible during erase/write operations. When the user
application code starts executing the interrupt vectors from the user flash area are active.
The user should either disable interrupts, or ensure that user interrupt vectors are active in
RAM and that the interrupt handlers reside in RAM, before making a flash erase/write IAP
call. The IAP code does not use or disable interrupts.
Since mbed-os 5.4.3, something increased foot print of mbed-os and the applications that were barely fitting in started to spill.
IAR toolchain for LPC176x target family is set to use 2 RAM regions (32K each). RAM region
2 is being used for ETH/USB and 1 is being used for vector table, stack/heap/static data.
In this commit we have decreased heap size allocation from 8K to 7K so that the is more room for stack and static data.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
Hugues Kamba
Harrison Mutai
Jaeden Amero
MarceloSalazar
Kevin Bracey
Chris Snow
Deepika
Przemyslaw Stekiel
David Saada
toyowata
Martin Kojtal
Jimmy Brisson
Hasnain Virk
Bartek Szatkowski
Brian Daniels
0x6d61726b
Christopher Haster