Using the nRF52840 Dongle (PCA10059) as a USB serial-to-BLE port

[SteveHx]

I have already read thru past inquiries along this line, and I see that many others are trying to do the same thing, but Nordic is still not providing appropriate example code. My product (actual several products for several clients) needs to use the BLE UART capability to get data into a PC. The most obvious application of the Dongle is for just this purpose. I also see that others have thought of trying to merge the USB-serial example with the UART-central example, none successfully that I found. Will Nordic provide such an example?

[SteveHx]

I'm still beating my head against a wall. The suggested tutorials address only v1.5.0, and the earliest I have installed is 1.6.1, current is 1.9.1.

The source code to run multi-NUS on the Dongle (and I think also on the 52840 DevKit) is fine, but without a project file which would set the appropriate options etc. I have downloaded and unzipped the code, but I find no way to open it under either the nRF Connect SDK nor under SES.

I am requesting a simple, step-by-step approach to actually running this example code, using either SES or nRF Connect SDK. Thank you.

[SteveHx]

"However, the project does not have the DFU trigger library so when the application is started (after completing DFU and resetting) nRF Connect Programmer will not find it, and therefor you get the error message."

A search finds some 100 files installed on my computer with "dfu_trigger" as part of the filename. How do i incorporate those into the multi-NUS project? Will the lack of that module prevent the multi-NUS app from running from a cold boot?

[Einar Thorsrud]

Hi,

SteveHx said:

The source code to run multi-NUS on the Dongle (and I think also on the 52840 DevKit) is fine, but without a project file which would set the appropriate options etc. I have downloaded and unzipped the code, but I find no way to open it under either the nRF Connect SDK nor under SES.

I am requesting a simple, step-by-step approach to actually running this example code, using either SES or nRF Connect SDK. Thank you.

Which example are you referring to now? The code WesC linked to is for the nRF5 SDK and will not work with the nRF Connect SDK. I assumed that was what you were testing, but that was perhaps not the case? If not, perhaps you can elaborate? (Also, the DFU trigger library I referred to is for the nRF5 SDK, as the bootloader the nRF52840 dongle ships with is nRF5 SDK based).

SteveHx said:

Will the lack of that module prevent the multi-NUS app from running from a cold boot?

No. The lack of the DFU trigger library only has two consequences:

1. it causes the nRF Connect programmer to output and error after programming.
2. You have to press the (sideways) reset button on the dongle in order to enter DFU mode when you want to program it.

SteveHx said:

"However, the project does not have the DFU trigger library so when the application is started (after completing DFU and resetting) nRF Connect Programmer will not find it, and therefor you get the error message."

Unless you find the above two points very annoying or problematic for your application, I suggest ignoring this (at least for now). If you want to add it at some point you can refer to examples/connectivity/ble_connectivity/main.c to see and example of it bing used.

[SteveHx]

Sorry that I seem to be tangling things up with my multiple attempts to get this to work. I'm trying to understand how to do the job, and trying not to become a tech support nightmare expecting you to do everything for me. I have tried for different combinations:

A) Choice of build environment: Either nRF5 SDK or nRF Connect. I am very familiar with the former, just getting my feet wet with the latter.

B) Choice of hardware platform: I need to run the Multi-NUS example code on both the nRF52840 devkit (which uses a real UART to talk thru the programmer chip as a USB serial port), and the nRF52840 Dongle (which has to have a USB serial port emulation running in the nRF52840 code).

I have been trying all four possible combinations of the two choices above. I would be more than happy to have either toolset work for either final target, even if they must differ. One place where I'm quite sure I'm just missing something simple, is how to load the multi-NUS code into nRF Connect - there doesn't seem to be any sort of project or configuration file. I would bet that a 15 minute zoom call where you could watch over my shoulder, would allow you to say "well, of course that doesn't work - you're supposed to do it THIS way". It might also generate suggestions you could make to the back-room boys to cut down on future tech support needs. I've been in this business for over 4 decades, and can usually figure it out on my own. Not so, this time.

[Einar Thorsrud]

Hi Steve,

SteveHx said:

A) Choice of build environment: Either nRF5 SDK or nRF Connect. I am very familiar with the former, just getting my feet wet with the latter.

There are good reasons for using either SDK. However, if you are starting with a new project now it might make sense to go for the nRF Connect SDK for the reasons laid out in the nRF Connect SDK and nRF5 SDK statement. However, the SDKs are completely different and there is no way to use an example from one SDK on the other (the APIs are vastly different). So if you have an example you want to use, you need to use it with the SDK it was written for.

SteveHx said:

B) Choice of hardware platform: I need to run the Multi-NUS example code on both the nRF52840 devkit (which uses a real UART to talk thru the programmer chip as a USB serial port), and the nRF52840 Dongle (which has to have a USB serial port emulation running in the nRF52840 code).

By "Multi-NUS example", are you referring to this unofficial example? This for the nRF Connect SDK (you can for instance see this because it has CMakeLists.txt and prj.conf). Also, it is for a rather old version so I assume you will need to make some adjustments to use it with the latest nRF Connect SDK release. I have not seen this example before to be honest, but from what I see in the code this use "normal" UART and not use USB-CDC, so if that is what you want to use then that must be added. Other than that, most samples work on any Nordic board as long as they depend on some HW resources that are not present on the specific board.

SteveHx said:

I have been trying all four possible combinations of the two choices above. I would be more than happy to have either toolset work for either final target, even if they must differ. One place where I'm quite sure I'm just missing something simple, is how to load the multi-NUS code into nRF Connect - there doesn't seem to be any sort of project or configuration file.

The project files here are the CMakeLists.txt and prj.conf and prj.overlay. This sample is built like any other nRF Connect SDK sample (but again, the problem is that it is a bit old). I suggest you start experimenting a bit with the nRF Connect SDK before you dive straight into this (or other unofficial and/or outdated samples).  As always, it makes sense to start with something like Blinky, and then move on. If you have not done so, you should start by installing the toolchain with the help of the toolchain manager. Then look at how to build and flash examples on the DK using VS code. Note that I do not recommend using Segger Embedded Studio with the nRF Connect SDK - you should use VS Code with the nRF Connect plugin. This is more user friendly, integrates better with the SDK and is what will be supported going forward.

SteveHx said:

I would bet that a 15 minute zoom call where you could watch over my shoulder, would allow you to say "well, of course that doesn't work - you're supposed to do it THIS way".

I suggest you contact your local FAE contact about that (send me a PM if you need their contact information).

SteveHx said:

It might also generate suggestions you could make to the back-room boys to cut down on future tech support needs. I've been in this business for over 4 decades, and can usually figure it out on my own. Not so, this time.

That is true. The nRF Connect SDK is still evolving and we are working hard to make it more user friendly, and any feedback that can help with that is welcome.