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.
The STM32WB Coridio driver includes:
- the Cordio HCI driver handling the reset sequence. During reset sequence
the TX POWER level is set and the BD address is defined if found in OTP
or option bytes. The rest of the sequence is based on the standard CORDIO
HCI driver example.
- The Transport Layer part handles sending and receiving messages to the
WB controller running on cortex-M0 of the STM32WB target. The messages
are shared through shared memory and mailboxes system based on IPCC HW.
Original AT traces had several issue:
- Can be overwritten by other traces (printf/mbed-trace)
- No way to know which direction message was going (TX or RX)
- <cr> and <ln> characters were not visible in trace
etc.
This commit addresses those issues using mbed-trace and showing separately
each filehandle write and read.
We provide now downlink channel frequency and time on air for the
received frame in the RX metadata.
Previously the channel information in both TX and RX metada contained
the index number of the channel. That information wasn't very useful
except the index numbers of default channels. To make more sense of the
meta data, we now store the channel frequency in the channel parameter
rather than the index number of the channel.
RX time on air is collected from the radio driver and it is assumed that
the downlink frame had 8 downlink preamble symbols (plus 4.25 of the
preambles added by the chip) for LoRa modulation.
This commit also include a bit of tidying of RX frequency storage in rx
configuration parameters storage. Previously we were missing filling in
the RX1 frequency correctly.
While calculating ack timeout, we were ending up getting a random value
which may become less than 2 seconds. This is not allowed as per v1.0.2
specification.
To fix the issue we now take the random number from 0 to 2000 ms and
then add that to the fixed 2000 ms ack timeout value, guaranteeing a
value at least equal to 2000 ms.
A bug while setting up RX start timers would result in premature closusre
of RX2 window. The 'ack_Timeout_timer' would be invoked prematurely and
at that time RX2 window may be being demodulating. This resulted in
massive instability with any test that relied on Confirmed traffic or
lower data rates.
To fix the issue, we must know the length of the RX window in
milliseconds and for this purpose we have extended the
'get_rx_window_params(...)' API. The length of the time the window
may remain open must be accounted for while setting up
'ack_timeout_timer'.