* Change "is supported" check to be a macro, so it can be done at
compile-time.
* Eliminate weird shift on 7-bit CRCs.
* Add support for 32-bit CRCs and reversals to TMPM3HQ.
* Change "is supported" check to be a macro, so it can be done at
compile-time.
* Eliminate weird shift on 7-bit CRCs.
* Add support for 32-bit CRCs and reversals to TMPM3HQ.
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.
By default, FLASH_SIZE should be read from HW.
In case this is not the case, we define it here, as the size of FLASH
that is available to the application running on M4.
the flash is shared and split between cortex-M4 that
runs (mbed-os) application and the cortex-M0+ that
runs the BLE firmware.
The 512K allocated to the application was a
conservative that can now be updated.
With recent up-to-date BLE firmware flashed @ 0x080CB000,
there should be 812K available to application.
But there are boards out there that don't have an up-to-date
firmware, so we're keeping an intermediate, safer,
application size of 768K.
Internal channels use is enabling ADC "internal path" which needs
to be disabled after measurement.
Same applied here for WB family as was done for others in #10143.
Typically the RTC clock is configured by RTC driver itself.
RNG on the other hand is shared with M0+ core and it is expected that
M4 turns it on at boot time.
When doing so, do not disbale GPIO clocks as they may be used by other
drivers !
As a result, debug will be disabled by default, but can be enabled by
either modifying code or selecting MBED debug profile.