BlueNRG-2 and Zephyr BLE - What changes in DTM is needed? (Bluenrg-MS has support in HCI driver in Zephyr BLE since 2018)

[Sebastien DENOUAL]

Hi @MMate.3​ ,

If you want to use BlueNGR-2 (DTM) and zephyr :

At first, I confirm BlueNRG-2 (flashed with DTM) is not supported by default with zephyr but for sure fully compliant.

• Key file to check on Zephyr side is "spi.c" (zephyr/drivers/bluetooth/hci/spi.c)

By default this zephyr file is designed to support BlueNRG-MS network behavior but overall behavior is similar to BlueNRG-2 flashed with DTM.

This, BlueNRg-MS is not build in LL_ONLY mode and can not be reflashed. This implies two steps in zephyr bluetooth spi project that are no more needed whiel adressing BlueNRG-2 DTM (LL_ONLY) :

• Trash BLUE_INITIALIZED_EVENT proprietary event sent by BleuNRG-MS at startup or reset
• Send specific command to enter LL ONLY mode - bt_spi_send_aci_config_data_controller_mode()

Those two upper steps are no more needed with BleuNRG-2 is you rebuilt your DTM image in LL_ONLY mode and could be cleaned from zephyr spi driver.

About SPI protocol with BleuNRG-2 DTM , no big changes vs BlueNRg-MS ( see file attached extracted from BlueNRg-2 SDK documentation)

Regards,

Sebastien

[MMate.3]

Hi Sebastien,

thanks for the confirmation that Zephyr is compliant with bnrg2/dtm.

My BlueNRG-2 is flashed with DTM fw I build (prebuild fw binaries did not work for me)

• the spi.c together with h4.c are the drivers I was inspired by when writing my uart based bluenrg driver. My BlueNRG-2 is connected to the host processor via UART interface. The driver I wrote is working and responding to all standard HCI commands during the bt_enable() call in Zephyr. I placed it in drivers/bluetooth/hci/bluenrg_uart.c. I am handling the VS events inside the driver to signalize bluenrg is ready (EVT_INITIALIZED). Also I am issuing the aci_config_data(0x2c, 1) to switch the BlueNRG/DTM to LL mode. But did not succeed to install gatt services, or better to say client side was not able to enumerate the services I declared.

• After I fail with switching to LL mode during runtime, I decided to rebuild the DTM firmware and get closer to it. So I added the LL_ONLY define to the new configuration based on UART configuration of DTM, called it UART_LL_ONLY. Build it and flashed it to BlueNRG-2. Indeed I no longer need to handle some events as before, because handling of EVT_INITIALIZED is apparently different with #define LL_ONLY. So I can confirm all what you wrote about the LL.

So only "big" difference is that I am using UART while BlueNRG-MS is using SPI (probably to simplify things as its fw cannot be changed as it is case of BlueNRG-2).

The problem which persist is that GATT services are added and handled using the VS ACI calls contrary to HCI standard. And switch to LL mode did not make much differences for me.

To summarize it, so far I am able to:

• init the chip/dtm
• open device and init the Zephyr/BLE stack
• start advertising - device visible on the multiple BLE tools for Android (GATT browser, ST toolbox, NRF tools)
• connect to the device - but no services are visible/enumerated on the client side.

One thing I've noticed is the handler values for basic GAP, GATT services (0x1 .. 0xb) are not properly initialized in the Zephyr/BLE srtack, but that is probably because these declarations are static and stored on the host flash).

Hoping that I will be able to solve this and thing I am very close to the solution, but still missing some important pieces.

Regards,

M.

[MMate.3]

Can you please share Zephyr project configuration?

Usually it is called prj.conf and it is placed in the Zephyr application folder.

[MMate.3]

Hi Sebastien,

I can confirm that enabling LL_MODE via VS command, or build the DTM with LL_ONLY solved the issue with connecting the BlueNRG2 to Zephyr BLE stack.

There was a bug in my hci_uart driver which in case of ACL packages read from the uart fifo directly instead of ring buffer serviced in the ISR.

I will pull request the driver into a main Zephyr tree. Meantime I can provide the files in case if anyone will be interested.

Thanks for your help and support.

M

[Sebastien DENOUAL]

Hi @MMate.3​ ,

Thanks for this feedback and your support to Zephyr community !

Indeed, "package read" management is slightly different with UART vs SPI implementation usually used.

There is no BLE functional differences between DTM-SPI and DTM_UART : same HCI commands set. All you can do with SPI is possible over UART.

The big difference between DTM UART and DTM SPI is the power management. Using DTM SPI, BlueNRG-2 will enter automatically sleep mode. The SPI_CS line is used to wake-up BlueNRG-2. And SPI_IRQ line is raised up by BlueNRG-2 to inform host MCU there is some data to be read on BlueNRG-2 side by host MCU.

Using DTM_UART, BlueNRg-2 cortex-M0 core is always active.

Regards,

Sebastien.

[RArte.1]

Hi,

I am trying to configure a simple sample/periodic_adv in my steval_stwinkt1 board with Zephyr SDK.

I compiled correctly, but the application raise an error with the rx_thread,

I attach the image with the error.

Could you help me?

I configured the steval_stwinkt1.dts by myself, and I can run other applications, like hts2221 temperature and humidity sensor application.

Here the error that I mentioned before.

 

Thanks! :grinning_face: