Problems with adding openthread to gcc BLE project

RE: Problems with adding openthread to gcc BLE project

marmio — Tue, 22 Aug 2017 07:41:16 GMT

ok, NRF_LOG_BACKEND_USES_ UART should be 0 ;)

RE: Problems with adding openthread to gcc BLE project

marmio — Tue, 22 Aug 2017 07:32:10 GMT

I had to do it once again and now I have one another problem with UART, When I leave as it is i get

/home/rolu/repos/openthread/examples/../examples/platforms/nrf52840/uart.c:243: multiple definition of `UARTE0_UART0_IRQHandler' _build/nrf52840_xxaa_nrf_drv_uart.c.o:C:\Users\Dell\Documents\nRF5_SDK_for_Thread_v0.10.0_e1c3d11\examples\multiprotocol\experimental\ble_app_att_mtu_throughput_rssi\pca10056\s140\armgcc/../../../../../../../components/drivers_nrf/uart/nrf_drv_uart.c:959: first defined here`

and when I change it to

#define APP_UART_DRIVER_INSTANCE 1
#define UART0_ENABLED            0
#define UART1_ENABLED            1

i get

../../../../../../../components/drivers_nrf/uart/nrf_drv_uart.h:82:19: error: 'UART0_CONFIG_USE_EASY_DMA' undeclared here (not in a function)
         (CONCAT_3(UART, id, _CONFIG_USE_EASY_DMA) == 1 ? \

how should I configure UART?

RE: Problems with adding openthread to gcc BLE project

Lukasz Duda — Wed, 16 Aug 2017 19:04:18 GMT

One side advice for extending ATT_MTU example with Thread protocol.

In the dynamic multiprotocol solution, the Timeslot API is used to achieve radio concurrency.

Softdevice always gives higher priority to BLE operations over Thread operations. ATT_MTU throughput example is designed to utilize the whole radio time usage between two connection intervals (of course only during the test).

Because of that Thread protocol will ungracefully try to get access to RADIO peripheral. In order to change this behaviour, you need to adjust two parameters in the ATT_MTU example to reduce the RADIO time usage on BLE from 100% to e.g. 25% (to give around 75% for Thread):

The event length and the connection interval are the primary parameters for setting the throughput of a connection. You need to change the first by reducing NRF_SDH_BLE_GAP_EVENT_LENGTH value in sdk_config.h from 320 (400ms) to smaller value e.g. 25% of connection interval (for connection interval of 400ms please use value of 80 (100ms)). This will effectively give around 300ms (75%) for Thread operations in between of BLE operations (but it will also reduce BLE throughput).
Turn off BLE_COMMON_OPT_CONN_EVT_EXT extension, please change conn_evt_len_ext_enabled parameter to false in the line number 155 of main.c:
```
  .conn_evt_len_ext_enabled = false
```
If this event extension option is enabled it will dynamically extend the event length when possible and so overwrite the value of NRF_SDH_BLE_GAP_EVENT_LENGTH.

In order to read more about event length and dynamic event length extension please follow infocenter documentation: infocenter.nordicsemi.com/index.jsp

In all our current examples Thread has around 95%+ of radio time, since BLE applications send small amout of data and the examples don't require special BLE parameters tunning. It is possible to design application that transfer large portion of data over Bluetooth LE with maximum throughput, however this operation should be as short as possible to allow Thread protocol to access the radio (eventually put Thread device into sleep mode - see SED example).

We will make sure to add description of effective BLE radio usage time and its configuration running concurrently with Thread, in the next nRF5 for Thread releases.

RE: Problems with adding openthread to gcc BLE project

Jørgen Holmefjord — Wed, 16 Aug 2017 13:45:43 GMT

Hi,

The first problem of multiple defines of RTC2_IRQHandler, is due to both OpenThread stack and ATT_MTU_throughput example using RTC2. ATT_MTU example use RTC2 for implementing a counter, and this counter needs to be implemented using other method/resources if you want to combine the OpenThread stack with this example. RTC0 and RTC1 cannot be used either, as these are used by the softdevice and app_timer respectively.

The other errors related to __flash_data_start/__flash_data_end could be caused by wrong linker script used for compilation. What Makefile/linker script do you use for your project? The default linker script for Thread/BLE multiprotocol examples are located in:

[THREAD_SDK_ROOT]/external/openthread/linker_scripts/openthread_nrf52840_multiprotocol.ld

Best regards,

Jørgen