Using custom BLE image on nRF52840 Dongle with Softdevice API on PC?

[Andreas Schurz]

Hi,

according to my system architect it should be possible to use a standard https://github.com/NordicSemiconductor/pc-ble-driver on the nRF52840 Dongle for implementing a BLE CDC on the dongle just by adjusting the relevant windows code.

What we want to achieve on the dongle:

Connect dongle to a PC, connect multiple devices (mobile phones) via BLE to the dongle

Provide a BLE Service with 2 characteristics

1. Read incoming string data with variable length from BLE connected device (mobile phone) and forward it to USB COM port, so that we can read it with a 3rd party software from the USB COM port.

2. Read incoming string data with variable length from USB COM port (3rd party writes to USB COM port), notify and forward it to connected BLE device (mobile phone)

This should be achievable by installation of a ready-to-use image on the dongle and all programming should be done on the windows side then. So that the dongle implementation must be never touched again.

Question:

Is this (still) possible? What is the latest solution on how to implement this?

I am aware that the pc-ble-driver is deprecated.

As already stated the idea is to update the device implementation without flashing the device.

If communication via USB COM is not possible this could also be handled within our Windows Softdevice API Application. USB COM would be more flexible.

Many thanks in advance.

Regards, Andreas

[Vidar Berg]

Hi,

I would not recommend using the pc-ble-driver for production, but it should be fine for testing purposes. In that case, the UART client sample should be a good starting point (https://github.com/NordicSemiconductor/pc-ble-driver/tree/master/examples/nordic_uart_client) 

You mention not wanting to re-flash the dongle, but would it be ok to re-program with DFU over USB? This can be performed without user intervention after they have plugged in the dongle and enable you to use a FW based on the nRF Connect SDK (see nRF52840 Dongle Programming Tutorial). 

I posted a modified version of the Central UART sample that works with the nRF52840 Dongle here:

 RE: Device Tree, proj.conf and strange uart behaviour  

This can be modified to use a custom GATT Client for your service and to support multiple connections.

Regards,

Vidar

[Andreas Schurz]

Ok. Thanks so far. This solution should be used in production later on. So pc-ble-driver is NO option then.

So what I understood is then:

• We will have to create our own implementation based on the Central UART example for the Dongle bei either using new (VS Code) or old (SEGGER) SDK
• It is not possible to change just a Windows EXE on the PC in order to fully change the Dongle BLE implementation
• We can reprogram it via DFU - so basically deploy the HEX or DFU.zip

Questions:

Did I get it right?

So the basic assumption from my system architect was that we can implement the complete Nordic BLE functionality in a windows exe without touching the Dongle implentation (no flashing and no-reprogramming). There would be an intial image and all updating in terms of Dongle functionality would be done by changing the windows exe.

In case this is not possible: can the re-programming then be automated, e. g. by using the command line while the dongle is connected. Idea here is to rollout images on a large number of PC-Based self-service machines all across the country and update the BLE implementation if needed. The Dongle will be plugged in all the time so the flash must be triggered remotely while the Dongle is connected. There is no one around who could replug the Dongle...

[Vidar Berg]

Yes, with this approach you will have the BLE application running on the dongle instead of the PC, as you would if you were using the pc-ble-driver. Therefore, any changes to the BLE functionality will require the dongle's FW to be updated. The FW does not have to be based on the Central UART, but I think this sample is the Bluetooth sample that most closely resembles your use case with the relaying of BLE data to the COM port.

DFU Trigger Library (USB) (Note: this has not been ported to the nRF Connect SDK) can be used to force the dongle into DFU mode without physical access to the device. When in DFU mode, you can use the 'nrfutil' tool from the command line to perform the DFU. 

[Andreas Schurz]

Thanks for the information but I am still confused.

Could you outine how the actual process from coding till the deployment works then? Which steps have to be taken and which tools have to be used from implementation to deployment?

So I do have to implement the code for the dongle using VS Code or Segger in C?

Using the trigger library to force DFU mode?

Then deploying via nrfutil?

Is this how it works then?

What does FW stand for? Firmware?

[Vidar Berg]

The nRF Connect SDK, which you can use to develop the firmware (FW), is primarily written in C. We recommend using it with VS Code and our nRF Connect extension. The hex file from your SDK project can then be programmed to the dongle using nrfutil, the programmer app in nRF Connect for Desktop, or an external debugging probe. Segger embedded studio is not supported in this SDK.

[Andreas Schurz]

Thanks for the response. That makes it all clear. We're planning to use a custom HW rather than the Dongle later, because the missing bridge is making it somehow more complicated. Therefore I will just develop it on a development board using the UART-to-USB bridge in the first step.

[Vidar Berg]

A development board is much more suited for development since it comes with an onboard Jlink debugger, so it is a good idea to use that. If you get a nRF52840 DK, you can use the second USB port on the side of the board if you later want to test the nRF USB, unless you plan to use a UART-to-USB bridge on your custom board as well.