Make it possible to specify a section of RAM that is not touched by
the init routing so data can be kept across resets.
This should behave the same as on atmega & lpc2387.
gcc9 started realizing that _sram is basically an uint8_t[1] and thus
HARDFAULT_HANDLER_REQUIRED_STACK_SPACE cannot be added to it without
exceeding the one-sized array.
This commit casts _sram to (uintptr_t) where that happens.
A second slot is defined with a calculated size, from the
remaining flash after the bootloader and the first slot.
Both slots are defined as equal size, but it can be overriden.
RIOTBOOT_SLOT_LEN is calculated as an hexadecimal value and
handles ROM_LEN defined as kilobytes like '512K'
This enables support for all the cortex-m0+/3/4/7 arch,
so most boards embedding these are potentially supported.
One needs just to ensure that the CPU can be initialised
at least twice.
Co-authored-by: Gaëtan Harter <gaetan.harter@fu-berlin.de>
This new function allows to jump to another execution
environment (VTOR) located at a certain (aligned) address.
It's used to boot firmwares at another location than
`CPU_FLASH_BASE`.
The user needs to ensure that the CPU using this feature
is able to be initialised at least twice while jumping
to the RIOT `reset_handler_default` function, since it
initialises the CPU again (calls cpu_init()).
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
Refactor cortexm_init to allow bits and pieces of
it to be called separately, while retaining the
current API, too. Needed for non-standard
Cortex-M initialisation, such as with nRF52
SoftDevice.
Allow defining a specific rom length to use for linking the firmware,
_fw_rom_length, instead of the default configuration to use the whole rom from
_rom_offset to the end.
* Add cortexm_common/Makefile.include FW_ROM_SIZE configuration
* Add an assertion that _fw_rom_length still respects _rom_length
Define _rom_offset with a conditional evaluated at execution time to allow
setting it in compilation rules and generate in the same make instance different
elf files with different configurations.
Before this change, if one tried to build a Cortex-M0+ target that had
an MPU, compilation would fail due to missing
'SCB_SHCSR_MEMFAULTENA_Msk' in SCB structure. Cortex-M0+ is a ARMv6-M
arch (unlike most other targets that have MPU support). ARMv6-M has more
limited support for fault conditions, see ARMv6-M Architecture Reference
Manual, D3.6.2.
The required space for the hardfault handler is defined by
HARDFAULT_HANDLER_REQUIRED_STACK_SPACE, which is given in bytes,
this length is added to &_sram to find a lower limit on the amount of
stack space that the hard fault handler can work with. The _sram
variable, was mistakenly defined as a uint32_t, which makes &_sram into
a uint32_t*, which through pointer addition, made the required space 4
times as big as it was supposed to. By changing the type of _sram to
uint8_t, the required stack space is correctly computed.
The symptom was that the hardfault handler always reported that the
stack pointer had been corrupted and it was impossible to get any useful
information from the crash text.
Instead of using `weak` function definitions, this PR handles
default implementations using `PROVIDES_x` defines, allowing
for cpus/pm realted modules to use their own implementations.
