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 TC flag is used in function serial_is_tx_ongoing to check if there is
an ongoing serial transmission. So this Flag must not be cleared at the
end of the transmission, otherwise, serial_is_tx_ongoing will notify that
TX is ongoing.
The impact is that it may prevent deep sleep to be entered.
Also there is no need to clear this flag at the end of the transaction
because it will be cleared automatically by HW when a new transmission
starts.
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
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 should strictly align to 8-byte boundary
Date is managed only by SW
within CUBE functions HAL_RTC_GetDate and HAL_RTC_SetDate.
They are then replaced by functions that saved counters in HW registers.
RTC_ReadTimeCounter and RTC_WriteTimeCounter are then added to the ST API.
As suggested by Russ Butler in mbed-os issue #7328, and until there is an
implementation of mbed-os issue #4408, we are implementing a workaround
at HAL level to check if there is any ongoing serial transfer (which happens
if HW FIFO is not yet empty).
In case a transfer is ongoing, we're not entering deep sleep and
return immediately.
In serial_tx_active and serial_rx_active functions,
we check the internal state value with
HAL_UART_STATE_BUSY_TX = 0x21U,
HAL_UART_STATE_BUSY_RX = 0x22U,
It seems that value can also be :
HAL_UART_STATE_BUSY_TX_RX = 0x23U,
- serial_init, serial_free and serial_baud function moved from serial_device.c (specific to each STM32 family) to serial_api.c (common STM32 file)
- default baudrate value was hardcoded to 9600
- Value is set now to MBED_CONF_PLATFORM_STDIO_BAUD_RATE for STDIO
- Value is set now to MBED_CONF_PLATFORM_DEFAULT_SERIAL_BAUD_RATE for other use
- UART init will not be stopped before calling serial_baud function
Re-casting with tmp the uint8_t* pData pointer to uint16_t* brings a
memory corruption and typically can corrupt the size parameter. This
is fixed with this commit.
STM32 Internal ticket reference : 39116
After reset the MCR register content needs to be restored so we're
introducing the can_registers_init function to be called at the first
init stage, but also after reset. We also store the can frequency to
go through the initialisation phase again.
Instead of a static object, this will make driver
instantiation more robust and allow to re-use init
configuration on a need basis.
The CANName struct member is actually the CAN registers base address,
which is now available in the CanHandle.Instance field, so we don't need
CANName anymore.
It is required to enable AFIO clock before using __HAL_AFIO_REMAP_xy
macros, which was missing here. Without clocks enable, the remap
actually doesn't occur. This would possibly cause some PIOs (part of
PB_3, PB_4, PA_13, PA_14, PA_15) to not behave as expected.
In most cases AFIO clock was enabled in stm_pin_SetAFPin function, so
that this bug was not visible. But there were few cases left were
stm_pin_DisconnectDebug would be called first. A typical case was
with GCC_ARM in case a DigitalInOut variable is declared as global.
jeromecoutant
MarceloSalazar
Alexandre Bourdiol
Martin Kojtal
Laurent Meunier
Kevin Bracey
int_szyk
Yuan Cao
Vincent Veron
deepikabhavnani
Cruz Monrreal
Marcin Tomczyk
Russ Butler
Przemyslaw Stekiel
Alastair D'Silva
David Saada
Cesar
bcostm
Paul Thompson
Cruz Monrreal
Jimmy Brisson
Martin Kojtal