A number of BLE roles depend on each other, checking within the target
configuration file for a valid configuration is infeasible. Move the
validation to the preprocessor and fail to compile if some required
roles are not enabled.
Two parameters are expected by the template:
- TPalSecurityManager a template class of the security manager of the form TPalSecurityManager<EventHandler>. The GenericSecurityManager is the event handler.
- SigningMonitor a template in the form SigningMonitor<Handler>.
GenericGattClient is parametized by two types:
- The template of the PalGattClient
- The SigningMonitorEventHandler
Note that the PalGattClient template must be of the form PalGattClient<EventHandler>. The event handler being the GenericGattClient.
Expected types are similar to the type expected by the constructor:
- PalGap
- PalSecurityManager
- ConnectionEventMonitorEventHandler
Note that for the PalGap we expect a **template** of the form PalGap<EventHandler>
The interface now lives in ::ble::interface::SecurityManager. The implementation type is expectected to exported as ble ::ble::impl::SecurityManager by the implementation.
The event handler has been extracted out of SigningEventMonitor declaration and SigningEventMonitor instantion requires the implementation and event handler type.
The event handler has been extracted out of SecurityManager declaration and instantion of the interface requires the implementation and event handler type.
The event handler has been taken out of GattClient declaration and an instantiation requires the actual implementation and the type that handle events.
The event handler has been taken out of Gap declaration and the instantiation must provide an implementation and the type that plays the event handler role.
After the patch RAM download is completed, a HCI reset should be sent in order to initialize the registers. Some of the initialization won't be called if the HCI reset is not sent after firmware download.
Fix the following build warning seen with both GCC and ARM_CC
[Warning] btle.cpp@115,0: #177-D: variable "clockConfiguration" was declared but never referenced
Add Cypress HCI driver implementation in TARGET_Cypress directory.
Update targets.json to enable CORDIO stack for Cypress PSoC 6 boards
with CYW43XXX radios with compatible HCI driver implementation:
CYW4343W and CYW43012.
TARGET_CYW4343X Bluetooth HCI driver is specific to STM32 targets
derived from USI_WM_BN_BM_22. Move the driver implementation to
TARGET_STM folder to not interfere with Cypress implementation at
TARGET_Cypress/TARGET_CYW43XXX/HCIDriver.cpp that is enabled for
PSoC 6 targets which also include the CYW4343X label.
The relationnal operators were targeting the base class which defines an implicit constructor to an integral value. This is wrong as it allows SafeEnum instances to be compared against integers.
The fix is simple: define relationnal operators for the derived class. The derived class is known as it is passed as a template parameter of the base class.
For extra safety the SafeEnum constructor is now explicit and protected.
Previously, the CryptoToolbox was allocated once as part of the security manager.
This was inneficient memory wise as it is only use to prepare key at initialization
and when we need to compute shared keys.
This was also inneficient power consumption wise as the Crypto cell was kept enabled even
when it wasn't used.
This fix creates a CryptoToolbox whenever it is needed and release it once it has fulfilled its
purpose. Note that CryptoToolbox allocation happens on the heap as mbed tls data structure are huge
and there's an high risk of crushing the stack.
the own_oob and peer_oob flags were not being set to 1 even though
an OOB pairing request was in progress, which therefore prevented
OOB data from being passed down to the softdevice during a OOB
pairing operation, thus causing the OOB pairing process to fail.
The function in the Nordic SDK for generating OOB data,
sd_ble_gap_lesc_oob_data_get, requires local LE Secure Connection
P256 Public Keys in {X,Y} format, but was being supplied with
the local secret key. This caused the generated OOB data to
fail to correspond to the Public Keys, which caused a mismatch
during the OOB pairing phase of the OOB confirmation value by
a remote peer when attempting to verify the OOB data against
the Public Keys, ultimately causing the OOB pairing request to
fail with a Confirm Value Failed (0x04) error.
The GenericSecurityManager tracks the most recent OOB data generated
by the PAL and the PAL function to generate OOB data is expected to
be asynchronous such that the OOB data is returned via a callback.
There was a race condition on the security manager's oob data variable
because it was cleared (set to all zeros) after calling PAL generate.
The expectation was that the clear operation would occur before the
callback executed, but this is proving to not be the case. Instead,
the callback is being executed as if it were syncronous with PAL
generate, then PAL generate returns and the oob data is cleared,
thereby losing the generated oob data that was set in the callback.
To fix the issue, clear the oob data variables before calling into
the PAL.
Fixes the following warning
[Warning] toolchain.h@24,0: #1215-D: #warning directive:
toolchain.h has been replaced by mbed_toolchain.h,
please update to mbed_toolchain.h [since mbed-os-5.3]