Multiperipheral UART Example

I am using 3 nrf52 DKs with S132 and SDK13 to try and implement a combination of the multilink and UART examples. I started with the ble_app_uart_c example and added the relevant code from the ble_app_multilink_central example to connect to multiple (in my case 2) peripherals via the NUS instead of the device name as it does in the multilink example. I programmed the two peripherals with the standard ble_app_uart example code, and it works -- the peripherals connect and I can see that the central has assigned connection handles to each of the devices.

However, when I try to send data from the peripherals to the central via a terminal I only get the output from one peripheral, and it's always the one that connected first. BUT if I connect both peripherals, and then unpower the one that connected first, the second one starts to work.

Has anyone seen this problem? One possible clue is the handles for the two devices. Namely, the nus_* handles are all zero for the second device. Could this be the problem?

The first peripheral: {uuid_type = 2 '\002', conn_handle = 0, handles = {nus_tx_handle = 18, nus_tx_cccd_handle = 19, nus_rx_handle = 16}, evt_handler = 0x22121 <ble_nus_c_evt_handler>}

And the second: {uuid_type = 2 '\002', conn_handle = 1, handles = {nus_tx_handle = 0, nus_tx_cccd_handle = 0, nus_rx_handle = 0}, evt_handler = 0x22121 <ble_nus_c_evt_handler>}

edit retag close delete

Sort by » oldest newest most voted

I found the problem with my code:

The two lines in ble_nus_c_evt_handler should actually have been:

ble_nus_c_handles_assign(p_ble_nus_c, p_ble_nus_evt->conn_handle, &p_ble_nus_evt->handles);
ble_nus_c_tx_notif_enable(p_ble_nus_c);


I was treating the pointer passed to ble_nus_c_evt_handler like the global variable m_ble_nus_c and trying to index into it, when in fact I already had the client handle.

more

Hi Villaran,

Seems that on the second device you haven't done service discovery. This explain why the nus_tx_handle was 0 . This is done by calling ble_db_discovery_start() when BLE_GAP_EVT_CONNECTED event occurred. Please have a look at on_ble_evt() event in main.c

Note that you would need an array to store the attribute table (the handles), if you have 2 devices, you need space for two tables. In the ble_app_uart example it's a single m_ble_db_discovery but in the multilink, it's an array m_ble_db_discovery[]

more

I am actually doing exactly that:

static ble_db_discovery_t       m_ble_db_discovery[TOTAL_LINK_COUNT];


And:

err_code = ble_db_discovery_start(&m_ble_db_discovery[p_gap_evt->conn_handle],
p_gap_evt->conn_handle);


The peripherals are connected to the central, but the BLE_NUS_C_EVT_NUS_TX_EVT only gets generated for the first device.

( 2017-07-17 17:12:48 +0200 )editconvert to answer

You need to check if the handle (for example nus_tx_handle ) return the correct handle. If not then it's impossible to receive the write command from the central. Were CCCDs enabled on both peripheral (writing 0x01 to CCCD characteristic).
You can try to capture a sniffer trace, it's easier to understand what exactly happens.

( 2017-07-17 17:18:02 +0200 )editconvert to answer

I have loaded the same code on to both peripherals -- it's just the standard ble_app_uart example code. But I really only need one-way communication from each peripheral to the central. I believe I'm assigning handles and setting the CCCDs for both peripherals with these lines when I get the BLE_NUS_C_EVT_DISCOVERY_COMPLETE:

err_code = ble_nus_c_handles_assign(&p_ble_nus_c[p_ble_nus_evt->conn_handle], p_ble_nus_evt->conn_handle, &p_ble_nus_evt->handles);
err_code = ble_nus_c_tx_notif_enable(&p_ble_nus_c[p_ble_nus_evt->conn_handle]);

( 2017-07-17 17:21:00 +0200 )editconvert to answer

The reason I asked to check the CCCD is to check if the the central manage to send write command correctly or not. If the central can manage to enable CCCD on both peripheral, there is no reason you couldn't do write command on the TX handle.

( 2017-07-18 13:04:01 +0200 )editconvert to answer

[hide preview]

Recent blog posts

• Flashing and Debugging nRF51/52 with a cheap blackmagic probe compatible SWD programmer

Posted 2017-07-24 09:32:02 by Mahesh Venkitachalam
• Introducing nRF5 SDK for Mesh

Posted 2017-07-20 09:42:44 by Pär H

Posted 2017-07-19 06:53:42 by Mohammad Afaneh
• Unique Thread/Bluetooth multiprotocol solution with nRF5 SDK for Thread and nRF52840 SoC by Nordic

Posted 2017-07-14 10:31:56 by Krzysztof Loska
• nRF Connect macros (currently Android only)

Posted 2017-07-14 13:29:14 by Aleksander Nowakowski

Recent questions

• Difficulty getting s132 SoftDevice working with UART example (uVision)

Posted 2017-07-26 04:24:31 by Drewster

• Recursive calls to "app_sched_execute" in nRF Bootloader flow

Posted 2017-07-26 03:16:21 by sdaexpert
• Need help with nRF5-SDK-13 and Eclipse Mars,2 Release 4.5.2

Posted 2017-07-26 02:49:04 by Sid Gilbrech
• want to write and read data to/from Flash?

Posted 2017-07-26 00:29:14 by vishal