Spotted in compiler warnings - code was trying to access a non-existent
second security control block, rather than access the settings for the
second APB bridge in the first and only security control block.
The hal code for this target uses "const volatile" types inside of
structs, which are non-trivially copyable in clang (used by ARMC6). This
causes the build to fail.
Here's the commit that changed this in clang:
a3d727ba77
It seems this was reverteed some time ago in clang, but ARMC6 may not
be up to date.
To have the flexibilty in application; to use any of the section
(data/bss/heap) without updating linker script in every use case,
following decisions are made:
1. Fixed size and small sections moved to SRAM2 (32K)
Vectors
Crash data
Remaining section - RW / ZI
2. Large memory space should be used for variable sections
RW/ZI
Heap - (Minimum - 0x12000)
Stack - At bottom
Fixes test failure seen with tests-mbed_hal-stack_size_unification
under IAR and ARM toolchain
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
This change moves all PDL drivers into common source and include
directories to alleviate issue with Windows version of GNU Make 4.x
maximum command line length limit.
New `target.console-uart` option added to indicate whether a target has
a console UART on STDIO_UART_TX/RX/RTS/CTS pins. (The existing option
`target.console-uart-flow-control` indicates whether RTS and or CTS is
available in addition to TX and RX).
The option defaults to true, and is currently true on all platforms. It
only applies if DEVICE_SERIAL is true, so no need to go through and mark
it false for non-SERIAL platforms.
An application can turn off target.console-uart to save ROM/power/etc if
they don't want to use the serial console. If this is turned off, the
console won't be activated for stdin/stdout, but the application is
still free to open `UARTSerial(STDIO_UART_TX, STDIO_UART_RX)`
themselves.
Since commit 12c6b1bd8, the i.MX RT1050 has effectively had its data
cache disabled, as the SDRAM was marked Shareable; for the Cortex-M7,
shareable memory is not cached.
This was done to make the Ethernet driver work without any cache
maintenance code. This commit adds cache maintenance and memory barriers
to the Ethernet driver, and removes the Shareable attribute from the
SDRAM, so the data cache is used again.
Cache code in the base fsl_enet.c driver has not been activated - the
bulk of it is in higher-level Read and Write calls that we're not using,
and there is one flawed invalidate in its initialisation. Instead
imx_emac.cpp takes full cache responsibility.
This commit also marks the SDRAM as read/write-allocate. As the
Cortex-M7 has its "Dynamic read allocate mode" to automatically switch
back to read-allocate in cases where write allocate is working poorly
(eg large memset), this should result in a performance boost with no
downside.
Activating write-allocate is also an attempt to provoke any flaws in
cache maintenance - the Ethernet transmit buffers for example will be
more likely to have a little data in the cache that needs cleaning.
Fixed interrupt vector settings on M0 core. Wrong vector settings prevented
LP_TICKER from working, resulting in deep sleep tests failing on M0
or PSA variant.
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.
Review HSE clock initialization to match with latest CUBE firmware.
Also there is no need to set the full clock tree again after deep sleep exit.
With this change we get a stable deep sleep mode (when allowed by CORDIO stack).
Until the CMSIS pack device name is officially deployed.
then we'll the name as can be found in Keil CMSIS pack
<!-- ************************* Device 'STM32WB55RG' ***************************** -->
<device Dname="STM32WB55RGVx">
<memory id="IROM1" start="0x08000000" size="0x001000000" startup="1" default="1" />
<memory id="IRAM1" start="0x20000000" size="0x000040000" init="0" default="1" />
<algorithm name="CMSIS/Flash/STM32WB_M4.FLM" start="0x08000000" size="0x001000000" default="1" />
<feature type="QFP" n="68"/>
</device>
There is no need to add FIRST attribute to MAPPING_TABLE as the default
ordering is alphabetical order.
With this change, we don't have any warning with MBED2 and the sections
are properly ordered anyway in BLE cases.
In case of mbed2, BLE feature is not built.
As there is a MAPPING_TABLE in BLE feature which is not compiled in case
of mbed2, the linker reported the below error
[ERROR] "C:/Data/Workspace/mbed/BUILD/test/NUCLEO_WB55RG/ARM/MBED_2/
.link_script.sct", line 65 (column 6): Error: L6236E:
No section matches selector - no section to be FIRST/LAST.
Solution is to check whether BLE is enabled.
These files are not BLE specific, but also needed for some clock setting
for instance.
In order to compile an MBED2 application, we need to move the files.
- move hw_conf.h file to targets/TARGET_STM/TARGET_STM32WB directory as
this is used also out of BLE feature.
- create a dedicated hal_deepsleep function as the behavior in WB is a lot
different from other existing STM32 targets
- update clock tree configuration to directly clock the entire tree @ 32MHz
out of HSE. This is needed as we want to let the M0 core running without
any change on M0-side of clocks when M4 enters /exits deep sleep.
Needed for PSoC to deep-sleep for more than 2 seconds
Max sleep with 16 bit lp_ticker (before this change) : 2sec
Max sleep with 32 bit lp_ticker (after this change) : 36hours
The cache must be refreshed when we erase or program flash memory.
It fix 2 issues :
Fix#9934Fix#6380
This solution was initially proposed in #6380.
Signed-off-by: Vincent Veron <vincent.veron@st.com>