apache / mynewt-nimble

Apache mynewt

Overview

Apache NimBLE is an open-source Bluetooth 5.4 stack (both Host & Controller) that completely replaces the proprietary SoftDevice on Nordic chipsets. It is part of Apache Mynewt project.

Feature highlight:

• Support for 251 byte packet size.
• Support for all 4 roles concurrently - Broadcaster, Observer, Peripheral and Central
• Support for up to 32 simultaneous connections.
• Legacy and SC (secure connections) SMP support (pairing and bonding).
• Advertising Extensions.
• Periodic Advertising.
• Coded (a.k.a. Long Range) and 2M PHYs.
• Bluetooth Mesh.

Supported hardware

Controller supports Nordic nRF51, nRF52 and nRF5340 chipsets as well as DA1469x (cmac) from Renesas. Host runs on any board and architecture supported by Apache Mynewt OS.

Browsing

If you are browsing around the source tree, and want to see some of the major functional chunks, here are a few pointers:

• nimble/controller: Contains code for controller including Link Layer and HCI implementation (controller)

• nimble/drivers: Contains drivers for supported radio transceivers (Nordic nRF51 and nRF52) (drivers)

• nimble/host: Contains code for host subsystem. This includes protocols like L2CAP and ATT, support for HCI commands and events, Generic Access Profile (GAP), Generic Attribute Profile (GATT) and Security Manager (SM). (host)

• nimble/host/mesh: Contains code for Bluetooth Mesh subsystem. (mesh)

• nimble/transport: Contains code for supported transport protocols between host and controller. This includes UART, emSPI and RAM (used in combined build when host and controller run on same CPU) (transport)

• porting: Contains implementation of NimBLE Porting Layer (NPL) for supported operating systems (porting)

• ext: Contains external libraries used by NimBLE. Those are used if not provided by OS (ext)

• kernel: Contains the core of the RTOS (kernel/os)

Sample Applications

There are also some sample applications that show how to Apache Mynewt NimBLE stack. These sample applications are located in the apps/ directory of Apache Mynewt repo. Some examples:

• blecent: A basic central device with no user interface. This application scans for a peripheral that supports the alert notification service (ANS). Upon discovering such a peripheral, blecent connects and performs a characteristic read, characteristic write, and notification subscription.
• blehci: Implements a BLE controller-only application. A separate host-only implementation, such as Linux's BlueZ, can interface with this application via HCI over UART.
• bleprph: An implementation of a minimal BLE peripheral.
• btshell: A shell-like application allowing to configure and use most of NimBLE functionality from command line.
• bleuart: Implements a simple BLE peripheral that supports the Nordic UART / Serial Port Emulation service (https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.0.0/s110/html/a00072.html).

External projects using NimBLE

Several other projects provide support for using NimBLE either by NPL port or forking:

• The Espressif ESP-IDF contains a NimBLE port for ESP-32 devices.
• The RIOT operating system contains a package for using NimBLE.
• The Open IOT SDK contains a NimBLE port based on CMSIS RTOSv2, which is an RTOS interface implemented by either Amazon Freertos, CMSIS RTX or Azure ThreadX.

If you publish a NimBLE port, please let us know to include it here!

Getting Help

If you are having trouble using or contributing to Apache Mynewt NimBLE, or just want to talk to a human about what you're working on, you can contact us via the developers mailing list.

Although not a formal channel, you can also find a number of core developers on the #mynewt channel on Freenode IRC or #general channel on Mynewt Slack

Also, be sure to checkout the Frequently Asked Questions for some help troubleshooting first.

Contributing

Anybody who works with Apache Mynewt can be a contributing member of the community that develops and deploys it. The process of releasing an operating system for microcontrollers is never done: and we welcome your contributions to that effort.

More information can be found at the Community section of the Apache Mynewt website, located here.

Pull Requests

Apache Mynewt welcomes pull request via Github. Discussions are done on Github, but depending on the topic, can also be relayed to the official Apache Mynewt developer mailing list [email protected].

If you are suggesting a new feature, please email the developer list directly, with a description of the feature you are planning to work on.

Filing Bugs

Bugs can be filed on the Apache Mynewt NimBLE Issues. Please label the issue as a "Bug".

Where possible, please include a self-contained reproduction case!

Feature Requests

Feature requests should also be filed on the Apache Mynewt NimBLE Bug Tracker. Please label the issue as a "Feature" or "Enhancement" depending on the scope.

Writing Tests

We love getting newt tests! Apache Mynewt is a huge undertaking, and improving code coverage is a win for every Apache Mynewt user.

License

The code in this repository is all under either the Apache 2 license, or a license compatible with the Apache 2 license. See the LICENSE file for more information.

mynewt-nimble's Issues

What's the advantage of this BLE stack compare the Nordic BLE stack?

[Ext adv] Add support for periodic advertising

This task is split to few subtasks:

• LL implementation for advertising - #354
• LL implementation for scanner - #440
• Host implementation - #283 #461
• btshell support - #461
• Sync Transfer (5.1 feature) - #651

Nimble does not persist CCCD value that was set before bonding

Here is a failing scenario:

1. Nimble is a peripheral
2. A connection is established with a peer device
3. Peer device subscribes for notifications/indications on a CCCD
4. Bonding with a peer device
5. Peer device disconnects and reconnects
6. The indication setting is not restored

GATT: Analyze and fix failing testcases when using AutoPTS

This is a general issue that groups all issues with GATT testcases when using AutoPTS. AutoPTS for Nimble is still work in process.

Test Case	Result
GATT/CL/GAR/BI-05-C	BTP ERROR	Read Characteristic Value - Insufficient Encryption Key Size
GATT/CL/GAR/BI-22-C	BTP ERROR	Read Multiple Characteristic Values - Insufficient Encryption Key Size
GATT/CL/GAW/BI-06-C	BTP ERROR	Write Characteristic Value - Insufficient Encryption Key Size
GATT/CL/GAW/BI-13-C	BTP ERROR	Write Long Characteristic Value - Insufficient Encryption Key Size
GATT/SR/GAD/BV-03-C	BTP ERROR	Find Included Services - from Server
GATT/SR/GAI/BV-01-C	BTP ERROR	Characteristic Value Indication - by Server
GATT/SR/GAN/BV-01-C	BTP ERROR	Characteristic Value Notification - by Server
GATT/SR/GAR/BI-05-C	BTP ERROR	Read Characteristic Value - Insufficient Encryption Key Size
GATT/SR/GAR/BI-11-C	BTP ERROR	Read Using Characteristic UUID - Insufficient Encryption Key Size
GATT/SR/GAR/BI-17-C	BTP ERROR	Read Long Characteristic Value - Insufficient Encryption Key Size
GATT/SR/GAR/BI-22-C	BTP ERROR	Read Multiple Characteristic Values - Insufficient Encryption Key Size
GATT/SR/GAR/BV-06-C	BTP ERROR	Read Characteristic Descriptors - from Server
GATT/SR/GAT/BV-01-C	BTP ERROR	Handle Value Indication - Client Timeout
GATT/SR/GAW/BI-06-C	BTP ERROR	Write Characteristic Value - Insufficient Encryption Key Size
GATT/SR/GAW/BI-13-C	BTP ERROR	Write Long Characteristic Value - Insufficient Encryption Key Size
GATT/CL/GAI/BV-01-C	BTP TIMEOUT	Confirm Characteristic Value Indication - by Client
GATT/CL/GAN/BV-01-C	BTP TIMEOUT	Characteristic Value Notification - to Client
GATT/CL/GAR/BI-14-C	BTP TIMEOUT	Read Long Characteristic Value - Invalid Handle
GATT/CL/GAR/BI-17-C	BTP TIMEOUT	Read Long Characteristic Value - Insufficient Encryption Key Size
GATT/CL/GAR/BI-18-C	BTP TIMEOUT	Read Multiple Characteristic Values - Read Not Permitted
GATT/CL/GAW/BI-07-C	BTP TIMEOUT	Write Long Characteristic Value - Invalid Handle
GATT/CL/GAW/BV-09-C	BTP TIMEOUT	Write Long Characteristic Descriptors - by Client
GATT/SR/GAR/BI-06-C	FAIL	Read Characteristic by UUID - Read Not Permitted Response
GATT/SR/GAR/BI-10-C	FAIL	Read Using Characteristic UUID - Insufficient Authentication
GATT/SR/GAD/BV-01-C	INCONC	Discover All Primary Services - from Server
GATT/SR/GAD/BV-02-C	INCONC	Discover Primary Services by Service UUID - from Server
GATT/SR/GAR/BV-04-C	INCONC	Read Long Characteristic Value - from Server
GATT/SR/GAR/BV-05-C	INCONC	Read Multiple Characteristic Values - from Server
GATT/SR/GAS/BV-01-C	INCONC	Service Changed Characteristic - from Server
GATT/SR/GAW/BV-01-C	INCONC	Write Without Response - to Server
GATT/CL/GAR/BV-04-C	PTS TIMEOUT	Read Long Characteristic Value - by Client
GATT/CL/GAW/BI-09-C	PTS TIMEOUT	Write Long Characteristic Value - Invalid Offset
GATT/SR/GAC/BV-01-C	PTS TIMEOUT	Server Configuration - of Server

Invalid handle should be used when disconnected

#289
When the device disconnect with peer node, should set the handle as invalid rather than 0.

L2CAP: Analyze and fix failing testcases when using AutoPTS

This is a general issue that groups all issues with L2CAP testcases when using AutoPTS. AutoPTS for Nimble is still work in process.

Test Case	Result
L2CAP/LE/CPU/BV-01-C	BTP TIMEOUT	Verify that the IUT is able to send the connection parameter update Request to tester when acting as a slave device.
L2CAP/LE/CPU/BI-01-C	PTS TIMEOUT	Verify that the IUT is able to reject a request for connection parameter update with illegal parameters.

L2CAP: static size of BLE_L2CAP_COC_MTU inefficient?!

Lately, I was playing with some stress-tests for sending data over raw l2cap connection oriented channels, and I had a lot of trouble with overflowing buffers. It took me a while to understand NimBLE's internal buffering for l2cap, but I think I have it figured out...

However, when looking more closely into the code, I found that BLE_L2CAP_COC_MTU in ble_l2cap_coc_priv.h is statically set to 100. If I understand it correctly, this value is only used for the computation of the initial credits for a connection (in ble_l2cap_coc_chan_alloc()). These credits then define the maximum number of 'mbuf's, that are allocated in a row from the msys pool, when ble_l2cap_coc_continue_tx() is called.

Example:

• open a l2cap channel with a MTU of 5000 byte -> the channel will initial have 50 credits (5000 + (BLE_L2CAP_COC_MTU - 1)) / BLE_L2CAP_COC_MTU
• now I want to send a chunk 5000 byte through the channel:
  • put the 5000 byte into an application specific mbuf pool
  • hand the data to NimBLE using ble_l2cap_send()
  • ble_l2cap_coc_continue_tx() is called. This function will allocate 50 mbufs from the msys pool, putting BLE_L2CAP_COC_MTU -> 100 byte of user data into each mbuf

-> on RIOT, MYNEWT_VAL_MSYS_1_BLOCK_SIZE is per default set to 292. This leads to a lot of wasted memory, as each of the 50 mbufs allocated above uses only 100 of these 292 byes, leaving 50 * ~190 byte -> ~9.5kb of RAM unused

So is there any reason I missed for setting BLE_L2CAP_COC_MTU statically to 100? I would suggest to set it simply to the value of MYNEWT_VAL_MSYS_1_BLOCK_SIZE, possibly minus a little overhead. Would that make sense?

Host notifies application of subscribe event before write response transmitted

Description

When a peer subscribes to a characteristic, the following sequence of events occurs:

1. Write request received (two-byte write to CCCD).
2. Host uses GAP event callback to tell application about subscription.
3. Host sends response to request from step 1.

The ordering of steps 2 and 3 is not ideal. If the application chooses to immediately send a notification or indication in step 2, the peer will receive it before the write response. It would be better if the host sent the response before it called the GAP event callback.

Possible implementation

On subscription, set a new flag in the CCCD entry and enqueue an event to the host event queue. When processed, the event would iterate the list of CCCDs, calling the GAP event callback for each whose flag is set.

Move BLE sample apps from core to nimble repo

We could have sample apps in nimble instead of core repo.
Since sample applications are OS specific we probably need to keep them per os eg apps/mynewt/ apps/freertos etc.

mesh: Race condition when processing message segments

Moved from apache/mynewt-core#1433
Original description:
"I found a multi-thread safety issue in mesh stack code and it still exist in the newest version.
When "seg_ack" was called by callout module, there was anthoer thread which receive mesh datas was calling "seg_rx_reset()" and set the "rx->sub" to NULL, then "seg_ack" called "send_ack" and acess the rx->sub->net_idx, so it crashed.
The adv-sending task and ble-data-receiving task and each "callout" are not in the same thread, why don't you add the Multi-thread protection mechanism in mesh stack? or something I used the wrong way?
Waiting for your replies! thank you so much!"
by @justabetterman

porting: Linux NPL needs better handling of timeouts in eventq

...in ble_npl_eventq_get

Add missing GATT descriptor UUIDs

The current release of nimble includes a define for the client characteristic configuration descriptor (0x2902). None of the other official descriptor UUIDs are present in ble_gatt.h.

In order to make use of the characteristic user description (0x2901), I currently have to define this myself or hard-code the value, both of which seem unfortunate.

Would it be appropriate to add at least the more commonly used ones, or does the current code operate under the premise that defines are only added as they are needed in the library itself or the larger mynewt-core repository? As limiting as that may be, I understand the goal of avoiding code bloat.

Semaphore maximum count is hardcoded to 128

In the API: ble_npl_sem_init, there is no way to define the maximum count for the semaphore being created, and this is left to the OS-specific implementation, like the API: npl_freertos_sem_init that defines this max value to 128.

Proposed solution: Add additional argument to the API: ble_npl_sem_init to define the maximum semaphore count, and this max value is to be passed to the OS-specific implementation.

IPv6 support over Bluetooth

Both over 4.2 as well as directly over extended advertising framework.

[travis] Pull requests should trigger automatic validation builds

All pull requests should be checked against potential build failures using some continuous integration service such as travis or other.

Even better would be for a unit test suite to run as well.

Can't see connection-oriented channel details

When an L2CAP connection-oriented channel is established, the application is notified via a BLE_L2CAP_EVENT_COC_CONNECTED event. This event contains a pointer to an struct ble_l2cap_chan object with all the details about the channel that was just connected. However, this struct is private (it is defined in nimble/host/src/ble_l2cap_priv.h), and there is no API to query the channel for details. So, the application cannot discover the CIDs or MTU of the channel.

Change a logging macro definition to avoid macro argument prescan

I have a suggestion regarding logging macros definitions from nimble/host/include/host/ble_hs_log.h.

Currently there are defined as follows:

#define BLE_HS_LOG(lvl, ...) \
    MODLOG_ ## lvl(LOG_MODULE_NIMBLE_HOST, __VA_ARGS__)

#define BLE_HS_LOG_ADDR(lvl, addr)                      \
    BLE_HS_LOG(lvl, "%02x:%02x:%02x:%02x:%02x:%02x",    \
               (addr)[5], (addr)[4], (addr)[3],         \
               (addr)[2], (addr)[1], (addr)[0])

The problem I encountered when porting mynewt-nimble to a new platform is that lvl argument of the BLE_HS_LOG_ADDR is prescanned. Very often external code uses the DEBUG macro (e.g. setting it to 1 or 0) and as a result nimble fails to compile.

Do you think it would be beneficial to change the BLE_HS_LOG_ADDR definition to avoid lvl argument expansion? For example, although a bit more verbose, it could be defined as

#define BLE_HS_LOG_ADDR(lvl, addr)                      \
    MODLOG_ ## lvl(LOG_MODULE_NIMBLE_HOST,              \
                   "%02x:%02x:%02x:%02x:%02x:%02x",     \
                   (addr)[5], (addr)[4], (addr)[3],     \
                   (addr)[2], (addr)[1], (addr)[0])

Cleanup and organize sample apps

applications in apps/ should be better organized. for example, we could have:

• apps/samples/ - sample apps which can be used as a base for creating own app (blehr, bleprph, blecent etc.)
• apps/tools/ - tools to hack NimBLE (btshell, blemesh etc.)
• apps/tests/ - various apps used as test app by developers (bletest)

nRF51 central not connecting with resolving and encryption enabled

Due to ble_ll_conn_rx_isr_end() taking too much time it is not possible to connect as a central with resolving and encryption enabled.

DHKey check failed when using rpa_pub on both sides

Pairing fails after initiator confirms passkey number.
Fails with reason "DHKey check failed (0x0b)". Tested using btshell with
the following configuration on both sides:

BLE_SM_BONDING: 1
BLE_SM_OUR_KEY_DIST: 7
BLE_SM_THEIR_KEY_DIST: 7
BLE_SM_IO_CAP: 4
BLE_SM_MITM: 1
BLE_SM_SC: 1
BLE_MONITOR_RTT: 1
BLE_EXT_ADV: 1
BLE_L2CAP_COC_MAX_NUM: 2
BLE_RPA_TIMEOUT: 600
BLE_EXT_ADV_MAX_SIZE: 1650
BLE_LL_CFG_FEAT_LE_2M_PHY: 1
BLE_LL_CFG_FEAT_LE_CODED_PHY: 1

Steps to reproduce

Device A:

advertise-configure connectable=1 legacy=1 scannable=1 own_addr_type=rpa_pub
advertise-set-adv-data flags=6 name=codecoup
advertise-start

Device B:

connect peer_addr=<rpa addr> peer_addr_type=random own_addr_type=rpa_pub
security-pair conn=1

Now there are two options:

Option 1:
Device B:

auth-passkey conn=1 action=4 yesno=y
Pairing fails here!

Option 2:
Device A:

auth-passkey conn=1 action=4 yesno=y

Device B:

auth-passkey conn=1 action=4 yesno=y
Pairing fails here!

bletiny application source is missing apps/ repo.

(G)ATT transactions shall be queued by host

NimBLE host seems to allow to send subsequent ATT requests without waiting for previous one to complete. This behavior is invalid as per Core 5.0, Vol 3, Part F, Section 3.3.2:

Once a client sends a request to a server, that client shall send no other request to the same server until a response PDU has been received.

We could just let application handle this, however:

1. it makes apps more complicated
2. there are already sample apps which seem to assume that multiple concurrent requests are handled properly (see blecent_read_write_subscribe in apps/blecent)

Since we already have ble_gattc_procs, we should leverage this to implement proper handling of GATT procedures inside host.

Host should read controller features during initialization

Host initializes controller assuming it's 5.0 with all features - this fails on 4.x controllers.
To fix this we should read controller features and adjust init sequence accordingly.

Mesh: Analyze and fix failing testcases when using AutoPTS

This is a general issue that groups all issues with Mesh testcases when using AutoPTS. AutoPTS for Nimble is still work in process.

Test Case	Result
MESH/NODE/CFG/NKL/BV-02-C	BTP TIMEOUT	Respond to Config NetKey Update Message
MESH/NODE/CFG/NKL/BV-03-C	BTP TIMEOUT	Respond to Config NetKey Delete Message
MESH/NODE/CFG/NKL/BV-04-C	BTP TIMEOUT	Receive Config NetKey Delete Message for Last NetKey
MESH/NODE/CFG/NTX/BV-01-C	BTP TIMEOUT	Respond to Config Network Transmit Get/Set Messages
MESH/NODE/CFG/RST/BV-01-C	BTP TIMEOUT	Receive Config Node Reset Message
MESH/NODE/CFG/SL/BI-01-C	BTP TIMEOUT	Respond to Config Model Subscription Add / Virtual Address Add Message (Invalid ElementAddress)
MESH/NODE/CFG/SL/BI-02-C	BTP TIMEOUT	Respond to Config Model Subscription Add / Virtual Address Add Message (Invalid Model Identifier)
MESH/NODE/NET/BV-04-C	BTP TIMEOUT	Send Mesh Message to All-proxies Address
MESH/NODE/CFG/CFGF/BV-01-C	FAIL	Respond to Config Friend Get/Set Messages. This test case relies on TSPC_MESH_7_3.
MESH/NODE/CFG/HBS/BV-02-C	FAIL	Receive Heartbeat messages - Controlled by PeriodLog State
MESH/NODE/CFG/NKL/BI-03-C	FAIL	Respond to NetKey Add Message (Insufficient Resources)
MESH/NODE/TNPT/BV-07-C	FAIL	Receive a Segmented Access Message - Unicast
MESH/NODE/TNPT/BV-12-C	FAIL	Receive Segmented Message - Receive New Segment After Incomplete Timer Expires
MESH/SR/PROX/BI-01-C	FAIL	Ignore Invalid Message Type
MESH/SR/PROX/BV-02-C	FAIL	Complete Message Network PDU Relay to Proxy Client
MESH/SR/PROX/BV-03-C	FAIL	Segmented Message Network PDU Relay to Proxy Client
MESH/SR/PROX/BV-04-C	FAIL	Send a Complete Message Network PDU to Node from Proxy Client
MESH/SR/PROX/BV-05-C	FAIL	Send a Segmented Message Network PDU to Node from Proxy Client
MESH/SR/PROX/BV-06-C	FAIL	Filter White List Addresses
MESH/SR/PROX/BV-08-C	FAIL	Filter Black List Addresses
MESH/SR/PROX/BV-09-C	FAIL	Remove Address from White List
MESH/SR/PROX/BV-10-C	FAIL	Remove Address from Black List
MESH/SR/PROX/BV-12-C	FAIL	Send Secure Network Beacon When IV Index Updated
MESH/SR/PROX/BV-13-C	FAIL	Send Secure Network Beacon with Previous IV Index Value
MESH/SR/PROX/BV-14-C	FAIL	IV Update Initiated by Proxy Client
MESH/NODE/CFG/HBP/BV-05-C	INCONC	Triggered publishing of Heartbeat messages - Low Power State changes (Provisioner)
MESH/NODE/TNPT/BV-08-C	INCONC	Receive a Segmented Access Message - Group/Virtual Address
MESH/SR/MPXS/BV-08-C	INCONC	Terminate Connection when the GATT Proxy Service Is Stopped
MESH/NODE/FRND/LPN/BV-02-C	PTS TIMEOUT	Friendship Messaging - Low Power Node
MESH/NODE/FRND/LPN/BV-07-C	PTS TIMEOUT	Friend Key Refresh - Low Power Node
MESH/NODE/IVU/BV-04-C	PTS TIMEOUT	Stay in IV Update In Progress Operation When Waiting On Segmented Message Transport PDU Acknowledgement
MESH/NODE/PROV/UPD/BV-09-C	PTS TIMEOUT	Provisioning Procedure, Procedure Timeout

BLE_EXT_ADV does not allow MESH to send messages

BLE_EXT_ADV does not allow bt_mesh_model_send to send the message.

The device is still able to receive the messages however.

This problem does not allow BLE and MESH to co-exist.

Assert failure when peer device enables 'notification' due to mismatch in conn_handle

Have submitted pull request #250 for this.

ble_ll_scan.c calls ble_ll_scan_init twice, which corrupts g_os_mempool_list

While troubleshooting why mpool cli command does not show anything beyond ble_ll_aux_scan_pool.

repro:

To watch it corrupt g_os_mempool_list, I did something like this following, where 0x20003648-0x2000364a is the pointer to the first of my missing mpool entries (via cli).

So, I didn't know what was altering the memory, and I didn't own JTAG w/ TRACE, so I wrote a small MWU IRQ to catch whatever was altering this memory. I then moved stack pointer back, so my Clion could show me the real offending stack. I setup the MWU after all usual inits of mpools ran (at which point g_os_mpool_list was still accurate), then it hit (corrupted) when the ble stack was coming up.

Let me know if you have some more clever way to watch memory on the ARM for changes, I am just learning how to debug more advanced stuff.

So, ble_ll_scan_init triggered it, but on the 2nd runthrough. So, my mpool was in the linked-list, but the 'new' mpool for ble_ll_scan_init was sorta replaced, and broke the linked list (cutoff any mpools after it).

This only occurs when BLE_LL_CFG_FEAT_LL_EXT_ADV is defined.

I will post a PR for the fix, verified it already.

------------- example code to catch this program in action------
void MWU_IRQHandler( void );
// start memory watch of 0x20003648 for debug
NRF_MWU->REGION[2].START = (uint32_t) 0x20003648;
NRF_MWU->REGION[2].END = (uint32_t) 0x2000364a;
//NRF_MWU->INTENCLR = MWU_INTENCLR_REGION3WA_Clear << MWU_INTENSET_REGION2WA_Pos;
NRF_MWU->INTENSET = MWU_INTENSET_REGION2WA_Enabled << MWU_INTENSET_REGION2WA_Pos;
NRF_MWU->REGIONENSET = MWU_REGIONENSET_RGN2WA_Enabled << MWU_REGIONENSET_RGN2WA_Pos;
NVIC_SetVector(MWU_IRQn, (uint32_t)MWU_IRQHandler);
NVIC_SetPriority(MWU_IRQn, (1 << __NVIC_PRIO_BITS) - 1);
NVIC_ClearPendingIRQ(MWU_IRQn);
NVIC_EnableIRQ(MWU_IRQn);

/* As the last thing, process events from default event queue. */
while (1) {
    os_eventq_run(os_eventq_dflt_get());
}

}

void HardFault_Handler() {
while (1) {
if (hal_debugger_connected()) {
/*
* If debugger is attached, breakpoint here.
*/
asm("bkpt");
}
NVIC_SystemReset();
}
}

void MWU_IRQHandler( void )
{
asm volatile(
" tst lr,#4 \n"
" ite eq \n"
" mrseq r0,msp \n"
" mrsne r0,psp \n"
" mov sp, r0 \n"
" bkpt #1 \n"
);
}

Missed AUX during scan should be indicated to host

If we miss AUX during chain scanning we should indicate this to host. Probably an empty ext adv report with data status "truncated" should be enough, but this should be verified with spec.

BLE Central: Requests with same opcode in quick succession do not work

If in a BLE GATT central, two or more requests with same opcode are sent (for e.g. Write or Subscribe to notify), the requests go through and responses are received. Although, the responses for all the requests except for the first one are not sent above to the app (or upper layers)

This is because, currently ble_gattc_extract_first_by_conn_op() extracts all the matching procs and then they are removed from the list. Ideally, it should extract the first matching proc (as its name suggests).

[Ext adv] Add support for filter duplicates in extended scanner

Nimble host should not assume conn_handle=0 as invalid.

There are instances in the host code that assumes conn_handle to be non-zero (e.g mesh provisioning cod e prov.c:is_pb_gatt). However, as per the specification, the value can be in the range: 0x000-0xEFF. This may make nimble host incompatible with other controllers.

Helper functions for subscribing to notifications / indications

Currently, an application subscribes to notifications or indications by performing a GATT write procedure on the appropriate CCCD. Knowing which two-byte pattern to write, and remembering to use little-endian, feels a bit too low-level to impose on the application developer.

I suggest we add two helper functions:

int
ble_gattc_subscribe_notifications(uint16_t conn_handle, uint16_t cccd_handle,
                                  ble_gatt_attr_fn *cb, void *cb_arg);
int
ble_gattc_subscribe_indications(uint16_t conn_handle, uint16_t cccd_handle,
                                ble_gatt_attr_fn *cb, void *cb_arg);

AUX_CHAIN_PDUs are always using same channel as superior AUX_ADV_IND

Each PDU could use separate channel to improve radio spectrum usage

Split UART transport into host and controller parts

nimble/transport/uart handles now both host and controller - we could split this into two separate transports to make maintaining code easier.

[portability] NimBLE should be C99 compliant

Nimble currently can't be compiled with -std=c99 flag passed to the compiler.

A number of errors will trigger when ISO C99 requirements are enforced.

bletest build errors

I want to use apps/bletest，but there were some errors

Compiling repos/apache-mynewt-core/hw/bsp/nordic_pca10040/src/hal_bsp.c
Assembling repos/apache-mynewt-core/hw/bsp/nordic_pca10040/src/arch/cortex_m4/gcc_startup_nrf52.s
Assembling repos/apache-mynewt-core/hw/bsp/nordic_pca10040/src/arch/cortex_m4/gcc_startup_nrf52_split.s
Error: repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c: In function 'bletest_send_ltk_req_neg_reply':
repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:84:28: error: passing argument 1 of 'ble_hs_hci_cmd_tx' makes integer from pointer without a cast [-Werror=int-conversion]
     rc = ble_hs_hci_cmd_tx(buf, &ack_conn_handle, 2, &rsplen);
                            ^
In file included from repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_priv.h:30:0,
                 from repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:39:
repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_hci_priv.h:74:5: note: expected 'uint16_t {aka short unsigned int}' but argument is of type 'uint8_t * {aka unsigned char *}'
 int ble_hs_hci_cmd_tx(uint16_t opcode, void *cmd, uint8_t cmd_len,
     ^
repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:84:10: error: too few arguments to function 'ble_hs_hci_cmd_tx'
     rc = ble_hs_hci_cmd_tx(buf, &ack_conn_handle, 2, &rsplen);
          ^
In file included from repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_priv.h:30:0,
                 from repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:39:
repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_hci_priv.h:74:5: note: declared here
 int ble_hs_hci_cmd_tx(uint16_t opcode, void *cmd, uint8_t cmd_len,
     ^
repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c: In function 'bletest_send_ltk_req_reply':
repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:107:28: error: passing argument 1 of 'ble_hs_hci_cmd_tx' makes integer from pointer without a cast [-Werror=int-conversion]
     rc = ble_hs_hci_cmd_tx(buf, &ack_conn_handle, sizeof ack_conn_handle,
                            ^
In file included from repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_priv.h:30:0,
                 from repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:39:
repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_hci_priv.h:74:5: note: expected 'uint16_t {aka short unsigned int}' but argument is of type 'uint8_t * {aka unsigned char *}'
 int ble_hs_hci_cmd_tx(uint16_t opcode, void *cmd, uint8_t cmd_len,
     ^
repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:107:10: error: too few arguments to function 'ble_hs_hci_cmd_tx'
     rc = ble_hs_hci_cmd_tx(buf, &ack_conn_handle, sizeof ack_conn_handle,
          ^
In file included from repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_priv.h:30:0,
                 from repos/apache-mynewt-nimble/apps/bletest/src/bletest_hci.c:39:
repos/apache-mynewt-nimble/nimble/host/include/../src/ble_hs_hci_priv.h:74:5: note: declared here
 int ble_hs_hci_cmd_tx(uint16_t opcode, void *cmd, uint8_t cmd_len,

Add support in controller for controller to host data flow control

We already have support for this in host, but need to add controller part. Right now we can just push data to host faster than it can process them and we can quickly run out of free buffers in msys pool.

Code Size Optimization

Currently we don't have code guards for most of the features that is configured through syscfg.h
so the code size will be considered large by having features disabled and its code is still exist.
Example:-
if we configure the host to work as a broadcaster only, There will be no connection. But all handling of connections will be available in ble_gap.c and ble_hs_hci_ev.c through dispatch tables. this will increase the image size unnecessarily with unused code.

Unprovisioned Beacons not sent when provisioning failed

Nimble does not start sending Unprovisioned Beacons after provisioning failure.
https://pastebin.com/pckSAZDi

APP: BleMESH

[Ext adv] Send scan req to peer device only once per scanning session unless ADI has changed.

GAP: Analyze and fix failing testcases when using AutoPTS

This is a general issue that groups all issues with GAP testcases when using AutoPTS. AutoPTS for Nimble is still work in process.

Test Case	Result
GAP/CONN/UCON/BV-06-C	BTP ERROR	Verify the IUT in the Undirected Connectable Mode using Resolvable Private Address can connect with another device performing the General Connection Establishment Procedure.
GAP/IDLE/NAMP/BV-01-C	BTP TIMEOUT	Verify the IUT can perform the Name Discovery Procedure and retrieve the device name from a peer device.
GAP/BROB/BCST/BV-03-C	INCONC	Verify the IUT in Broadcast Mode using a resolvable private address.
GAP/CONN/CPUP/BV-02-C	INCONC	Verify the IUT can perform the Connection Parameter Update Procedure using valid parameters for the peer device; the peer device fails to respond in a timely manner.
GAP/CONN/CPUP/BV-03-C	INCONC	Verify the IUT can perform the Connection Parameter Update Procedure using invalid parameters for the peer device; the peer device accepts the updated connection parameters.
GAP/BOND/BON/BV-01-C	PTS TIMEOUT	Verify that the IUT can properly initiate bonding procedure and store bonding information after pairing while in bondable mode as peripheral role.
GAP/BOND/BON/BV-03-C	PTS TIMEOUT	Verify that the IUT can properly response to bonding and store bonding information after pairing while in bondable mode as peripheral role.
GAP/BOND/BON/BV-04-C	PTS TIMEOUT	Verify that the IUT can properly respond to bonding and store bonding information after pairing while in bondable mode as central role.
GAP/BOND/NBON/BV-03-C	PTS TIMEOUT	Verify that the IUT does not exchange or store bonding information after pairing while in non-bondable mode.
GAP/CONN/CPUP/BV-01-C	PTS TIMEOUT	Verify the IUT can perform the Connection Parameter Update Procedure using valid parameters for the peer device; the peer device accepts the updated connection parameters.
GAP/CONN/PRDA/BV-01-C	PTS TIMEOUT	Verify that the IUT can properly respond to connections after bonding when Private Random Addresses are used by the Lower Tester.
GAP/GAT/BV-01-C	PTS TIMEOUT	Verify that the IUT had all the mandatory GAP characteristics.
GAP/IDLE/NAMP/BV-02-C	PTS TIMEOUT	Verify the IUT can support the Name Discovery Procedure and allow a peer device to retrieve the device name.
GAP/PRIV/CONN/BV-10-C	PTS TIMEOUT	Verify the IUT in the Undirected Connectable Mode supporting the Privacy feature can connect with another device performing the General Connection Establishment Procedure. The IUT is operating in the Peripheral role.
GAP/SEC/AUT/BV-11-C	PTS TIMEOUT	Verify that the IUT properly rejects the service request when there is no sufficient bonding and then completes service correctly with Lower Tester as central role.
GAP/SEC/AUT/BV-12-C	PTS TIMEOUT	Verify that the IUT properly rejects the service request when there is no sufficient bonding and then completes service correctly with Lower Tester as peripheral role.
GAP/SEC/AUT/BV-13-C	PTS TIMEOUT	Verify that the IUT properly rejects the service request when there is insufficient authentication and then completes service correctly with Lower Tester as peripheral role.
GAP/SEC/AUT/BV-14-C	PTS TIMEOUT	Verify that the IUT properly rejects the service request when there is insufficient authentication and then completes service correctly with Lower Tester as peripheral role.
GAP/SEC/AUT/BV-17-C	PTS TIMEOUT	Verify that the IUT can pair with a device who's I/O capabilities do not allow an authenticated pairing, after a service request has been denied with the error response "Insufficient Authentication".
GAP/SEC/AUT/BV-18-C	PTS TIMEOUT	Verify that the IUT can pair with a device who's I/O capabilities do not allow an authenticated pairing, after a service request has been denied with the error response "Insufficient Authentication".
GAP/SEC/AUT/BV-20-C	PTS TIMEOUT	Verify that the IUT when bonded with a peer device tests the bond when receiving the error response "Insufficient Authentication", if link is unencrypted, before eventually removing the bond to perform a new pairing.
GAP/SEC/AUT/BV-21-C	PTS TIMEOUT	Verify that the IUT will inform the upper layer about a lost bond, if the link is refused to be in encrypted with the LTK distributed during the prior pairing procedure.
GAP/SEC/AUT/BV-22-C	PTS TIMEOUT	Verify that the IUT will inform the upper layer about a lost bond, if the peer refuses to encrypt the link with the LTK distributed during the prior pairing procedure.
GAP/SEC/AUT/BV-23-C	PTS TIMEOUT	Verify that the IUT properly rejects the service request when the required pairing has occurred and encryption is required (LE security mode 1) but encryption is not enabled and then completes service correctly with Lower Tester as central role.
GAP/SEC/AUT/BV-24-C	PTS TIMEOUT	Verify that the IUT properly rejects the service request when the required pairing has occurred and encryption is required (LE security mode 1) but encryption is not enabled and then completes service correctly with Lower Tester as peripheral role.

mesh: Multi-thread safety issue

I found a multi-thread safety issue in mesh stack code and it still exist in the newest version.
When "seg_ack" was called by callout module, there was anthoer thread which receive mesh datas was calling "seg_rx_reset()" and set the "rx->sub" to NULL, then "seg_ack" called "send_ack" and acess the rx->sub->net_idx, so it crashed.
The adv-sending task and ble-data-receiving task and each "callout" are not in the same thread, why don't you add the Multi-thread protection mechanism in mesh stack? or something I used the wrong way?
Waiting for your replies! thank you so much!

Extended Advertisement Issues

Greetings,

I'm not 100% sure I'm using it correctly, but I am attempting to send 200byte (or larger I hope), packets over ble_ext_adv using phy-1m (with a goal to test phy-2m on secondary). I have a test project which shows the following issues, and allows for a bit of stress testing against this part of nimble.

Test Project:
https://github.com/mwilliford/mynewt-extadv-test

Issues:

• Initially, lots of asserts.
• Apply diff to nimble, maybe a little better, heavy corruption though.
• Issue with scanning stopping after 5-10min. I see no BLE_GAP_EVENT_DISC_COMPLETE when it
  stops. I know it stops because r resetting the 'other' board does not fix it. Only resetting the board
  which stops decoding messages fixes it.

NOTE: There is a file called nimble.diff which is an attempt to work around asserts, but it likely leaves the stack in a bad state, as the above issues might be related to a bigger state issue.

Mesh: Use ble_gap_event_listener_register() instead of ble_gap_mesh_cb_register()

It seems we don't need ble_gap_mesh_cb_register() anymore

SM: When SM is disabled, `ble_sm_tx` is called without a host lock

Configuration:

BLE_SM_LEGACY: 0
BLE_SM_SC: 0

When pairing is attempted with a device with SM disabled, it leads to a this code path being executed, which calls ble_sm_tx without holding the host lock:
https://github.com/apache/mynewt-nimble/blob/master/nimble/host/src/ble_sm.c#L2743

The debug check inside ble_sm_tx asserts because the host lock is not held:
https://github.com/apache/mynewt-nimble/blob/master/nimble/host/src/ble_sm_cmd.c#L56

Update ICS and btshell instructions to run PTS

SM: Analyze and fix failing testcases when using AutoPTS

This is a general issue that groups all issues with SM testcases when using AutoPTS. AutoPTS for Nimble is still work in process.

Test Case	Result
SM/SLA/KDU/BV-07-C	FAIL	Verify that the IUT correctly handles a requested encrypted session setup to use the distributed LTK, EDIV and Rand values when the key distribution phase has completed
SM/SLA/PKE/BV-05-C	FAIL	Verify that the IUT that supports the Passkey Entry pairing procedure as responder correctly handles an initiator with insufficient security to result in an Authenticated key
SM/SLA/SIE/BV-01-C	FAIL	Verify that the IUT is able to initiate encryption as a slave
SM/SLA/SIP/BV-01-C	FAIL	Verify that the IUT is able to initiate a pairing as a slave

Unit tests need some more consistent way of starting host

Some unit tests start host multiple times after various configuration steps which may be hard to manage properly without some workarounds in code. We should try to have more consistent and easier to maintain way of starting host. See #279 for an example of issue.

Missing include of nimble_npl.h

Hi,

I've been trying to set up a hello-world following https://mynewt.apache.org/latest/tutorials/ble/ble_bare_bones.html but the newt build ble_tgt fails with

Error: In file included from repos/apache-mynewt-nimble/nimble/drivers/nrf52/src/ble_hw.c:34:0:
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:125:46: error: unknown type name 'ble_npl_event_fn'; did you mean 'ble_npl_stime_t'?
 ble_npl_event_init(struct ble_npl_event *ev, ble_npl_event_fn *fn,
...

And other errors related to missing type definitions which are present in repos/apache-mynewt-nimble/nimble/include/nimble/nimble_npl.h. Tried adding "@apache-mynewt-nimble/nimble"
to my pkg.deps section of the tutorial app's pkg.yml but no success. Is there something else I should do which is missing from the tutorial?

The project definition I'm using (after following newt-core nimble dependency error #1096):

project.name: "my_project"

project.repositories:
    - apache-mynewt-core
    - apache-mynewt-nimble

repository.apache-mynewt-core:
    type: github
    vers: 0-dev
    user: apache
    repo: mynewt-core

repository.apache-mynewt-nimble:
   type: github
   vers: 0-dev
   user: apache
   repo: mynewt-nimble   

Full error log is below and it seems that all are caused by not including nimble_npl.h

...
Compiling repos/apache-mynewt-nimble/nimble/host/src/ble_att.c
Compiling repos/apache-mynewt-nimble/nimble/host/src/ble_att_clt.c
Error: In file included from repos/apache-mynewt-nimble/nimble/drivers/nrf52/src/ble_hw.c:34:0:
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:125:46: error: unknown type name 'ble_npl_event_fn'; did you mean 'ble_npl_stime_t'?
 ble_npl_event_init(struct ble_npl_event *ev, ble_npl_event_fn *fn,
                                              ^~~~~~~~~~~~~~~~
                                              ble_npl_stime_t
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:152:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:158:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:164:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:170:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:176:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:182:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:196:22: error: unknown type name 'ble_npl_event_fn'; did you mean 'ble_npl_stime_t'?
                      ble_npl_event_fn *ev_cb, void *ev_arg)
                      ^~~~~~~~~~~~~~~~
                      ble_npl_stime_t
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:201:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:245:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/porting/npl/mynewt/include/nimble/nimble_npl_os.h:251:15: error: unknown type name 'ble_npl_error_t'
 static inline ble_npl_error_t
               ^~~~~~~~~~~~~~~
repos/apache-mynewt-nimble/nimble/drivers/nrf52/src/ble_hw.c: In function 'ble_hw_rng_init':
repos/apache-mynewt-nimble/nimble/drivers/nrf52/src/ble_hw.c:337:9: error: implicit declaration of function 'ble_npl_hw_set_isr'; did you mean 'ble_npl_sem_init'? [-Werror=implicit-function-declaration]
         ble_npl_hw_set_isr(RNG_IRQn, (uint32_t)ble_rng_isr);
         ^~~~~~~~~~~~~~~~~~
         ble_npl_sem_init
cc1: all warnings being treated as errors

NimBLE does not stop advertising threads on reset_cb

When internal error occurs, controller is reset, while MESH advertising threads are not stopped. This results in controller being out of sync with host.

https://pastebin.com/MQ67ug73