The existing test was expecting that the acknowledgement of the reset command would be the first and only event receive. This assumption is false.
As a consequence, the new code parse all incoming packets and raise a flag in the following circumstances:
* a reset packet has been successfully received.
* RX stream is not synchronized
* The status of the reset command is an error.
Another test has been added that send a serie of reset commands.
The first test focuse on the transport by testing that the reset sequence is
correctly sent to the controller and properly received.
The second test validates that the reset sequence fullfill the right state
of the stack and ensure that bluetooth initialization succeed.
A peer device that sends a connection parameter update may get block if it doesn't receive a response.
This patch accept the peer request unconditionnally. At some point this event will be managed by the application.
Depending on the role and the current state of the local device; pairing cancelation should be made with a call to a specific function. Normally the Nordic stack would reject invalid calls if the device is not in the correct state; therefore it was assumed that it was possible to detect the state from sd errors. Unfortunatelly this is not true with the latest softdevices as some calls succeed even if the device is not in the right state.
To solve that issue cancelation looks at the current state of the device first to select the right function that will trigger the pairing cancellation.
Note: the call to sd_ble_gap_authenticate was missing in the previous algorithm
A friend class living in the namespace ble::vendor::cordio and named CordioHCITransportDriver can be added in applications requiring access to internal data of the HCI driver and HCI transport driver.
This is meant to be internal and not easily exploitable by application code.
* CENTRAL_LINK_COUNT
* PERIPHERAL_LINK_COUNT
* gatts_enable_params.attr_tab_size
* gatts_enable_params.service_changed
* common_enable_params.vs_uuid_count
These settings control the range of functionality enabled in the softdevice as well as ram consumption.
In particular reducing these values is critical to enable usage of 16K nrf51 devices.
The soft device is not consistent as it is required to force the connection to a resolved resolvable address so it should be known if the target is an identity address.