Using Zephyr and Bluetooth (and other peripherals)

RE: Using Zephyr and Bluetooth (and other peripherals)

CktDesigner — Tue, 05 Jan 2021 03:49:19 GMT

Thanks!

RE: Using Zephyr and Bluetooth (and other peripherals)

Kenneth — Mon, 04 Jan 2021 10:26:56 GMT

Hi,

I made an example with spi some time ago:
https://devzone.nordicsemi.com/f/nordic-q-a/66488/using-spi-with-ppi-in-zephyr/272139#272139

I am thinking you may be missing the IRQ_CONNECT() if you want to use nrfx directly.

Kenneth

RE: Using Zephyr and Bluetooth (and other peripherals)

CktDesigner — Sun, 03 Jan 2021 19:41:50 GMT

OK, thanks. I looked at the example you linked to.

Is the DeviceTree overlay file required, or can the nrfxlib calls defining peripheral instances, etc. be used directly?

Also, any comment on the other question from the earlier entry (how to determine the number of free BLE notify buffers available)?

Update:

After a lot of reading and trial/error, I was able to get the nrfx TWIM driver interface to work using C calls to initialize and initiate transfers, but only in blocking mode.

From the example you linked to in DevZone, I found that prj.conf should have:

# I2C
#CONFIG_I2C=y
#CONFIG_I2C_NRFX=y
#CONFIG_I2C_1=y
CONFIG_NRFX_TWIM1=y

but after some trial/error found that only the last statement is really needed, so the first 3 CONFIG_ statements are commented out.

Here is the code segment I used to declare and initialize the interface:

void
i2cHandler(nrfx_twim_evt_t const *evtPtr, void *contextPtr) {
  printk("TWIM Event\n");
}

  // I2C instance
nrfx_twim_t i2c1= NRFX_TWIM_INSTANCE(1);

void main(void) {
  int err;

  // Initialize interfaces

  // I2C configure
  nrfx_twim_config_t i2cConfig = {
    .scl =                 I2C_SCL_PIN,
    .sda =                 I2C_SDA_PIN,
    .frequency =           NRF_TWIM_FREQ_400K,
    .interrupt_priority =  NRFX_TWIM_DEFAULT_CONFIG_IRQ_PRIORITY,
    .hold_bus_uninit =     false
  };
  err= nrfx_twim_init(&i2c1,
                      &i2cConfig,
                      (nrfx_twim_evt_handler_t)i2cHandler,
                      //NULL,
                      NULL);
  if(NRFX_SUCCESS != err) {
    printk("I2C driver init failed: %d\n", err);
  }
  nrfx_twim_enable(&i2c1);

where I2C_SCL_PIN is defined as (NRF_GPIO_PIN_MAP(0,27)), etc.

And here is a snip of code where I write to an I2C peripheral to initialize it.

  #define LM75A_ADDR       0x48
  #define LM75A_REG_CONF   0x01
  #define LM75A_REG_TEMP   0x00
  uint8_t initWrite[] = { LM75A_REG_CONF, 0x00 };
  uint8_t readWrite[] = { LM75A_REG_TEMP };
  uint8_t readBuf[2];
  nrfx_twim_xfer_desc_t lm75aInit = {
    .type             = NRFX_TWIM_XFER_TX,
    .address          = LM75A_ADDR,
    .primary_length   = sizeof(initWrite),
    .secondary_length = 0,
    .p_primary_buf    = initWrite,
    .p_secondary_buf  = NULL
  };
  nrfx_twim_xfer_desc_t lm75aRead = {
    .type             = NRFX_TWIM_XFER_TXRX,
    .address          = LM75A_ADDR,
    .primary_length   = sizeof(readWrite),
    .secondary_length = 2,
    .p_primary_buf    = readWrite,
    .p_secondary_buf  = readBuf
  };
#if 1
  err= nrfx_twim_xfer(i2cPtr,&lm75aInit,0);
  if(NRFX_SUCCESS != err) {
    printk("TWIM error during init!\n");
  }
#endif

This only works when the first "NULL" is uncommented, and the i2cHandler statement is commented out in the "init" statement (making TWIM run in blocking mode). So the interface works in blocking mode.

But if I run with the "init" as shown above (i2cHandler declared and the "NULL" commented out, so it should run in non-blocking mode), a run-time error is reported:

[00:00:00.345,550] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 1: Unhandled interrupt on CPU 0[0m
[00:00:00.345,581] [1;31m<err> os: Current thread: 0x200024a0 (BT ECC)[0m
[00:00:00.760,314] [1;31m<err> fatal_error: Resetting system[0m
*** Booting Zephyr OS build v2.4.0-ncs2  ***
[00:00:00.336,914] [0m<inf> sdc_hci_driver: SoftDevice Controller build revision: 
cf 5c 0f 11 88 9c d7 02  15 27 c7 c3 ca 60 19 85 |.\...... .'...`..
b7 c4 50 e3                                      |..P.             [0m
[00:00:00.340,545] [0m<inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)[0m
[00:00:00.340,545] [0m<inf> bt_hci_core: HW Variant: nRF52x (0x0002)[0m
[00:00:00.340,545] [0m<inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 207.3932 Build 3617359889[0m
[00:00:00.342,071] [0m<inf> bt_hci_core: Identity: d4:7d:d9:fe:63:8d (random)[0m
[00:00:00.342,102] [0m<inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x1123, manufacturer 0x0059[0m
[00:00:00.342,102] [0m<inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x1123[0m

and the board (nRF52840-DK) reboots (and everything repeats as the error occurs again).

It looks like Zephyr is receiving an interrupt (presumably the TWIM completion) that it is not ready for. I suspect that I haven't properly initialized something, but am unsure what... I suspect that there has to be some linkage between the HW interrupt and the TWIM driver.

I was expecting "i2cHandler" to be called when the I2C xfr completed.

Can you give me some pointers?

Thanks...

RE: Using Zephyr and Bluetooth (and other peripherals)

CktDesigner — Tue, 29 Dec 2020 21:16:23 GMT

OK, thanks. I looked at the example you linked to.

Is the DeviceTree overlay file required, or can the nrfxlib calls defining peripheral instances, etc. be used directly?

Also, any comment on the other question from the earlier entry (how to determine the number of free BLE notify buffers available)?

Update:

After a lot of reading and trial/error, I was able to get the nrfx TWIM driver interface to work using C calls to initialize and initiate transfers, but only in blocking mode.

From the example you linked to in DevZone, I found that prj.conf should have:

# I2C
#CONFIG_I2C=y
#CONFIG_I2C_NRFX=y
#CONFIG_I2C_1=y
CONFIG_NRFX_TWIM1=y

but after some trial/error found that only the last statement is really needed, so the first 3 CONFIG_ statements are commented out.

Here is the code segment I used to declare and initialize the interface:

void
i2cHandler(nrfx_twim_evt_t const *evtPtr, void *contextPtr) {
  printk("TWIM Event\n");
}

  // I2C instance
nrfx_twim_t i2c1= NRFX_TWIM_INSTANCE(1);

void main(void) {
  int err;

  // Initialize interfaces

  // I2C configure
  nrfx_twim_config_t i2cConfig = {
    .scl =                 I2C_SCL_PIN,
    .sda =                 I2C_SDA_PIN,
    .frequency =           NRF_TWIM_FREQ_400K,
    .interrupt_priority =  NRFX_TWIM_DEFAULT_CONFIG_IRQ_PRIORITY,
    .hold_bus_uninit =     false
  };
  err= nrfx_twim_init(&i2c1,
                      &i2cConfig,
                      (nrfx_twim_evt_handler_t)i2cHandler,
                      //NULL,
                      NULL);
  if(NRFX_SUCCESS != err) {
    printk("I2C driver init failed: %d\n", err);
  }
  nrfx_twim_enable(&i2c1);

where I2C_SCL_PIN is defined as (NRF_GPIO_PIN_MAP(0,27)), etc.

And here is a snip of code where I write to an I2C peripheral to initialize it.

 #define LM75A_ADDR       0x48
  #define LM75A_REG_CONF   0x01
  #define LM75A_REG_TEMP   0x00
  uint8_t initWrite[] = { LM75A_REG_CONF, 0x00 };
  uint8_t readWrite[] = { LM75A_REG_TEMP };
  uint8_t readBuf[2];
  nrfx_twim_xfer_desc_t lm75aInit = {
    .type             = NRFX_TWIM_XFER_TX,
    .address          = LM75A_ADDR,
    .primary_length   = sizeof(initWrite),
    .secondary_length = 0,
    .p_primary_buf    = initWrite,
    .p_secondary_buf  = NULL
  };
  nrfx_twim_xfer_desc_t lm75aRead = {
    .type             = NRFX_TWIM_XFER_TXRX,
    .address          = LM75A_ADDR,
    .primary_length   = sizeof(readWrite),
    .secondary_length = 2,
    .p_primary_buf    = readWrite,
    .p_secondary_buf  = readBuf
  };
#if 1
  err= nrfx_twim_xfer(i2cPtr,&lm75aInit,0);
  if(NRFX_SUCCESS != err) {
    printk("TWIM error during init!\n");
  }
#endif

If I run with the "init" as shown above (i2cHandler declared and the "NULL" commented out, so it should run in non-blocking mode), a run-time error is reported:

[00:00:00.345,550] ·[1;31m<err> os: >>> ZEPHYR FATAL ERROR 1: Unhandled interrupt on CPU 0·[0m
[00:00:00.345,581] ·[1;31m<err> os: Current thread: 0x200024a0 (BT ECC)·[0m
[00:00:00.760,314] ·[1;31m<err> fatal_error: Resetting system·[0m
*** Booting Zephyr OS build v2.4.0-ncs2 ***
[00:00:00.336,914] ·[0m<inf> sdc_hci_driver: SoftDevice Controller build revision:
cf 5c 0f 11 88 9c d7 02 15 27 c7 c3 ca 60 19 85 |.\...... .'...`..
b7 c4 50 e3 |..P. ·[0m
[00:00:00.340,545] ·[0m<inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)·[0m
[00:00:00.340,545] ·[0m<inf> bt_hci_core: HW Variant: nRF52x (0x0002)·[0m
[00:00:00.340,545] ·[0m<inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 207.3932 Build 3617359889·[0m
[00:00:00.342,071] ·[0m<inf> bt_hci_core: Identity: d4:7d:d9:fe:63:8d (random)·[0m
[00:00:00.342,102] ·[0m<inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x1123, manufacturer 0x0059·[0m
[00:00:00.342,102] ·[0m<inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x1123·[0m

and the board (nRF52840-DK) reboots (and everything repeats as the error occurs again).

I was expecting "i2cHandler" to be called when the I2C xfr completed.

Can you give me some pointers?

Thanks...

RE: Using Zephyr and Bluetooth (and other peripherals)

Kenneth — Tue, 29 Dec 2020 14:38:34 GMT

Maybe you can check out:
https://devzone.nordicsemi.com/f/nordic-q-a/65900/change-sda-and-scl-pin-for-i2c1-on-nrf5340/269646#269646

RE: Using Zephyr and Bluetooth (and other peripherals)

CktDesigner — Tue, 22 Dec 2020 02:51:10 GMT

Hi Kenneth,

Is there an example that shows how to configure using an nrfxlib peripheral driver (for example TWIM) with Zephyr? (I tried adding the line: CONFIG_I2C_NRFX=1 to the prj.conf file.)

Thanks!

RE: Using Zephyr and Bluetooth (and other peripherals)

CktDesigner — Thu, 17 Dec 2020 20:24:23 GMT

Hi Kenneth,

Thanks for the links. Even though I had spent a lot of time reading, I missed some of these documents (perhaps due to looking in the Zephyr links instead of the Nordic/Zephyr links).

I am still a bit confused on using Notifications when using BLE with Zephyr. Under nRF5 SDK, a callback (BLE_GATTS_EVT_HVN_TX_COMPLETE) indicates how many notifications have been sent (by traversing the pointer properly (p_ble_evt->evt.gatts_evt.params.hvn_tx_complete.count)) during a connection interval. This allows one to monitor how many TX buffers are being used/available. (My application under nRF5 FreeRTOS was overrunning the buffers...)

Under Zephyr, I see that a callback can be requested when sending a notification (bt_gatt_notify_cb). The callback indicates that the notification has been sent, but I don't see a way to get a count of how many have been sent. Can I assume that this callback will occur for each notification (and that if multiple notifications are sent in a single connection interval, multiple callbacks will occur)?

Thanks again!

RE: Using Zephyr and Bluetooth (and other peripherals)

Kenneth — Thu, 17 Dec 2020 13:32:16 GMT

Hi,

The mass-production silicon of the nRF5340 is now available, so I recommend to order a new nRF5340-DK:
https://www.digikey.no/product-detail/en/nordic-semiconductor-asa/NRF5340-DK/1490-NRF5340-DK-ND/13544603

The nRF5340 Preview DK (PDK) is not really recommended anymore for development.

To get started with the nRF5340-DK you must use the nRF Connect SDK (NCS). The NCS is using the Zephyr RTOS:
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.1/nrf/getting_started.html
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.1/nrf/ug_nrf5340.html#

You can choose between using the zephyr BLE controller or the nordic softdevice controller:
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.1/nrf/ug_ble_controller.html#

Typically you can find that bluetooth sample applications in nrf/samples/bluetooth are using nordic softdevice controller, while sample applications in zephyr/samples/bluetooth are using zephyr BLE controller. Typically you choose nordic softdevice controller by setting CONFIG_BT_LL_SOFTDEVICE_DEFAULT=y in prj.conf. I suggest to continue to use the softdevice controller.

If you are familiar with nRF5 SDK you may find this blog post useful:
https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/software/posts/building-a-ble-application-on-ncs-comparing-and-contrasting-to-softdevice-based-ble-applications

I suggest to look at the throughput example on how to adjust ATT MTU, DLE and PHY:
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.1/nrf/samples/bluetooth/throughput/README.html

The zephyr native drivers are good to use if you want to use any of the ready-made libraries in zephyr that rely on the api of the native drivers, if you don't need those, then you may as well use the nrfx directly. I do not believe the libraries in nRF5 SDK are ported to NCS, I don't know how easy this will be.

If you are trying out the nRF5340 make sure to program the network core with the HCI RPMsg sample (using the BLE controller you want to use):
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.1/nrf/ug_nrf5340.html#network-samples

Then the application core can be programmed with the BLE sample application, you can also find this described here:
https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started/posts/nrf-connect-sdk-tutorial---part-1-ncs-v1-4-0#h67sk646yl2d1o7b0c616t5mlg1flcovq

In general you may find these tutorials useful to get started:

https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started/posts/nrf-connect-sdk-tutorial

https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started/posts/ncs-ble-tutorial-part-1-custom-service-in-peripheral-role

https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started/posts/nus-on-ncs-the-nordic-uart-service-with-the-nrf-connect-sdk

Best regards,
Kenbeth

RE: Using Zephyr and Bluetooth (and other peripherals)

CktDesigner — Wed, 16 Dec 2020 15:40:08 GMT

One additional question:

When using S140 in my nRF52840 application, in order to get higher performance when using Notifications, I increased the size of the HVN TX queue. I keep track of the number of available queue slots (as recommended in the Nordic documentation), only issuing a Notification when a slot is available. Is there an equivalent mechanism when using the Zephyr bluetooth interface? If so, can you point to documentation (or an example on how to maximize throughput using Notifications in Zephyr)?