nRF52840 Dongle programming for Windows

[EdwinP]

I need to write a Windows program that talks to the nRF52840 Dongle.  Is there a .dll or .lib or source code for communicating with the Dongle?  I have programmed the dongle with s140_nrf52_6.1.0_softdevice.hex.  I can not find any documentation of the actual interface that is seen on the PC.  Is it just operated via commands over the COM port?  Are these commands documented?  Where can I find this documentation?

I also need an application to use the nRF52840 Dongle in a pass-through UART mode.  Do I need to load a different hex file into it for that?  Where can I get that?  Is there documentation of the GATT service and characteristic UUIDs for this code?

Thanks!

[Einar Thorsrud]

Hi,

You can program the nRF52840 with the connectivity firmware (ser_s140_usb_hci) if you want to control it from a PC over USB. On the PC side you would use the pc-ble-driver, or a higher level application that use it (such as nRF Connect for Desktop or nrfutil). The pc-ble-driver then communicates with the nRF using the serialization API.

What exactly do you mean by passthrough UART mode? UART to BLE? If so, then the NUS service used in the ble_app_uart example that you already found is what you need. You can program the SDK example, but as the nRF52840 dongle does not have an onboard debugger this needs to be done via USB DFU, as explained under  Getting started and Programming in the nRF52840 dongle documentation. Not that there are some issues with the current version of the nRF Connect programmer, so you may be better of using the nrfutil command line tool at this point in time.

[EdwinP]

Sorry, I am still having some problems.

1. I searched for ser_s140_usb_hci that you mention but I don't find it anywhere.  Can you provide a link?  What is it?

2. nRF Connect only shows 5 apps I can run.  One of them (Bluetooth Low Energy) installs software on the dongle before running and runs successfully.  This is the only way I have found to put code containing SoftDevice into the dongle.  I have read the Getting Started and Programming links.

3. I have tried to use the Programmer app launched by nRF Connect.  This gives me the error "Only a single writable region is supported".  Why is this?  I can program an app that does not use SoftDevice, but, for example, connectivity_2.0.1_1m_with_s132_5.0.hex in pc-ble-driver-master\hex\sd_api_v5 contains SoftDevice and will not program this way.

4. I have tried nrfjprog, but I get this error: "ERROR: There is no debugger connected to the PC."

5. I have tried nrfutil.  I first ran this command to make a DFU package (no errors):

nrfutil pkg generate --hw-version 52 --sd-req 0x9D --application-version 5 --application connectivity_2.0.1_1m_with_s132_5.0.hex app_dfu_package.zip

I then ran this command:

nrfutil dfu usb_serial -pkg app_dfu_package.zip -p COM4 -b 115200

which, after some chatter, gives this error:

pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice.

I pushed the button on the dongle to make the red light flash before doing this.  How do I use nrfutil to program the Dongle?

[EdwinP]

Here is some more info:

I managed to make a package that nrfutil will program into the Dongle using this command:

nrfutil pkg generate --hw-version 52 --sd-req 0x8C --application-version 5 --application connectivity_2.0.1_1m_with_s132_5.0.hex app_dfu_package.zip

This is confusing because the documentation output from nrfutil says FWID 0x8C is the code for s132_nrf52_3.0.0, and the code for s132_nrf52_5.0.0 should be 0x9D.  Is this a documentation bug?

In any case, after programming the dongle with this, I no longer see any COM ports from the dongle.

Now what do I do?

Is is possible for you to give me a list of programs to run with command line arguments to get to the point where I can see a com port from the dongle that communicates with my bluetooth device that is handling the other end of the BLE_UART?

[Einar Thorsrud]

Hi, 

You will not get the NUS to UART over USB out of the box, as we do not have any such example for the nRF52840 dongle. You have to implement it yourself. Either by making a NUS to USB serial bridge firmware for the nRF52840 yourself, or by using the connectivity firmware and pc-ble-driver approach that we have discussed. In that case you have to implement most of the functionality on the PC side (including the Nordic UART firmware), as the nRF52840 will simply be a connectivity chip.

Alternatively, if this is something you want to get done quickly for using it as a debug tool or similar, you would be much better of getting a nRF52840 DK (or another nRF52 DK for that matter), which has onboard debugger that has the UART over USB to NUS "bridge" already implemented (via the onboard Segger debugger IC that does the USB-UART bridging).

Regarding the --sd-req option to nrfutil this depend on the SoftDevice that is already programmed to the device, so assuming it is version 3, then you should state that your app requires it.

[EdwinP]

OK, I would like to use the pc-ble-driver approach.  I choose sd_api_v5, which seems to have four choices for hex file.  I chose connectivity_2.0.1_1m_with_s132_5.0.hex to load onto the dongle.  I don't understand your answer about --sd-req.  Am I not programming the dongle with a new SoftDevice when I program this hex file into it?  And isn't this hex file the SoftDevice for s132 nRF52 5.0.x as the filename implies?  Why does the --sd-req option need to be 0x8C instead of 0x9D?  After I program this file, even if I do it again, I still need 0x8C, not 0x9D.  Does this mean I have not programmed the desired SoftDevice into the dongle?  Is there another step I'm missing?  Also, I don't understand what you mean by this: "so assuming it is version 3, then you should state that your app requires it."

Also, I still have the problem that when I program the dongle, it does not expose any COM ports.  I must not have the correct procedure for programming the SoftDevice into the dongle.  Please explain how to do it.

I did run the Bluetooth Low Energy app from nRF Connect and it works.  It downloads code into the dongle.  Can you tell me exactly what hex file and/or what version is loaded into the dongle by this program?  I understand need my PC app to match this if I am to interface to it.  Also what baud rate does it use?

I thought I would start by modifying the example heart rate monitor hrm_v5.  First I compiled and ran it with the dongle as programmed by nRF Connect.  It gives this output:

Serial port used: COM7
Baud rate used: 1000000
Info: Successfully opened COM7. Baud rate: 1000000. Flow control: none. Parity: none.

Status: 6, message: Target Reset performed
Status: 7, message: Connection active
Warning: Failed to receive response for command
Status: 4, message: Error sending packet to target. Code #3
sd_ble_cfg_set() failed when attempting to set BLE_GAP_CFG_ROLE_COUNT. Error code: 0x03

I looked at the code around the call to sd_ble_cfg_set() and the online API documentation.  The docs show this function as having 3 arguments, but the example code gives it 4 arguments.  I looked specifically at the docs for S132 SoftDevice v5.0.0 API, which the example supposedly links with. (It is linking with pc_ble_driver_static_sd_api_v5.lib.)  Can you explain this?

I see there is a file in the hex folder called sdk150_add_sd_v3v5_support.patch.  What do I do with this file?

I downloaded s140_nrf52_6.1.0.zip.  Is that the latest version of SoftDevice?  There is no .lib file in that .zip.  Where can I find something like pc_ble_driver_static_sd_api_v?.lib for s140?

Thank you for your help with this.

[Einar Thorsrud]

Hi,

There is a lot of different topics in this thread, and I fear a few misunderstandings. I will try to answer most one by one:

• The bootloader is originally made as for using Bluetooth as a transport layer, and there you should normally not combine the SoftDevice and application in a single hex and use that for DFU in the bootloader (It is typically too large, and the SoftDevice is needed for upgrade over BLE). When you provide the application with --application <hex>, this typically needs that a specific SoftDevice is present in the flash in order to run, and the bootloader will check the version number provided with the --sd-req and only provide the option if it matches. This check may not be needed for the USB bootloader, as the app and bootloader may not depend on the SoftDevice. I suspect that the reason you need to repeatedly use the version number for a older SoftDevice is that the previous upgrade did not complete, so that the existing SoftDevice in flash has not changed. You can check the flash using e.g. nrfjprog to verify this. Note that you can also skip SoftDevice version checking using --sd-req 0x00 (0x00 meaning any SoftDevice version)
• You should not expect the nRF52840 dongle to show up as a UART device without firmware that implements it. The connectivity_2.0.1_1m_with_s132_5.0.hex firmware that you used is made for the nRF52832 DK, which does not have onboard USB. (It uses the UART peripheral, and the onboard Segger debugger to bridge UART <-> USB.
• If you get nRF Connect to work with the Bluetooth Low Energy app, then it means that the connectivity firmware is in place in the nRF52840 so all should be good there. nRF Connect use a modified version of the connectivity firmware in the SDK. You can find the needed patches to the SDK project here.
• You can check all details of the connectivity firmware and adapt it to your needs by looking at the project for it under <SDK 15>\examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci\.
• It seems sd_ble_cfg_set() returned NRF_ERROR_INTERNAL (0x03). The function takes three parameters in S140 version 6.0.0, as you can see from the API documentation. Where do you see four parameters used?
• The patch file you mention sdk150_add_sd_v3v5_support.patch is to adapt the SDK example connectivity firmware to the needs of nRF Connect. I do not know the details of this. I suggest you create a separate thread if you want to know the reasoning behind the changes.
• Yes, S140 version 6.1.0 is the latest SoftDevice for the nRF52840. What kind of lib or zip are you after? Currently, the S140 version 6.1.0 is not used by any other released distributions, but you can adapt existing projects to it (there is no API changes so it should be fast). The next SDK, version 15.1.0, will include eS140 version 6.1.0.

[EdwinP]

Thank you for answering many of my questions.  Sorry, I still have some:

Yes, nRF connect loads Bluetooth Low energy.  My question is exactly what hex file is loaded when I do that?  What version of SoftDevice and what application code?  I would be happy to interface my PC code to that code if I knew what it was and had documentation on how to interface to it.

I tried to compile the project in nRF5_SDK_15.0.0_a53641a\nRF5_SDK_15.0.0_a53641a\examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci\arm4 and I get the error

cannot open source input file "core_cm4.h"

from many files.  It seems this project isn't set up correctly.  I am able to compile the project in ...\ser_s140_usb_hci\arm5_no_packs, but I cannot link with the fre version of Keil I am using.  Do I need to buy a license for Keil (over $1500) to get this hex file?  Can you send the hex file to me?  Also, do I need the arm4 version or the arm5_no_packs version or will either work with the nRF52840 dongle?

sd_ble_cfg_set() is called with four arguments on line 322 of main.c in the project hrm_v5 which is in pc-ble-driver-master\examples\heart_rate_monitor.  This program compiles, so I am confused as to the discrepancy between the code and the documentation.

The heart rate monitor example hrm_v5 is a PC program that links with pc_ble_driver_static_sd_api_v5.lib, which should talk to the dongle running the app connectivity_2.0.1_1m_with_s132_5.0.hex and presumably a SoftDevice s132.  I understand that I cannot use this code with the dongle because it uses the UART, not the USB port.  The application that I have seen work is the Bluetooth Low Energy, but I do not have any source code for that.  Do you have source code for that?  I would expect a hex file for the version of the SoftDevice used (perhaps s140_nrf52_6.1.0_softdevice.hex which I have), another hex file for the application, a .lib file and some .h files for the PC application to link to the API which is documented online except for how to link to it or where these files are, and some code for the actual Bluetooth Low Energy application.  If I had that, I could write the code that I need for my application.

My question about the .patch file is how does one use it?  I don't know if I need it.  I don't see any documentation.

You say I can use nrfjprog with the dongle.  Is that the only way to write a new SoftDevice into the dongle, using nrfjprog (or segger, etc.) through p1?

Maybe you have an answer for this: What is the quickest way for me to write PC code that will talk to the nRF 52840 dongle?  Can I do it without compiling new code for the dongle (since Bluetooth Low Energy already does this)?  How do I get the needed hex code into the dongle?

Thank you so much for your help with this.  Unfortunately, my client need this functioning in a very short time frame, so your help is greatly appreciated.

[Einar Thorsrud]

Hi,

Perhaps it would be better to separate this thread into multiple threads with fewer questions when continuing this? It would make it easier to get an overview. 

• I expect that the .hex file used by the nRF Connect BLE app is the SDK 15 connectivity example project patched with the patch files from pc-ble-driver, probably from the v6-upgrade branch (I have not been able to verify that, though).
• You can see the details of how to apply the patch in the pc-ble-driver documentation section Compiling the connectivity .hex files.
• Regarding the sd_ble_cfg_set() I misunderstood and though you were building using SDK 15 for running locally on the nRF. You should refer to the relevant pc-ble-driver API documentation in the relevant header files (ble.h) if you are building a PC side app. Generally, the serialization API has an additional parameter which is the adapter.
• I am not sure why you are getting the cannot open source input file "core_cm4.h" error. However, I do not recommend using the old arm4 project (this are for the outdated Keil 4). As you do not have a Keil license I recommend you to use GCC ("armgcc" folder) or Segger Embedded Studio ("ses" folder) instead.
• You cannot use the connectivity_2.0.1_1m_with_s132_5.0.hex example app out of the box. As mentioned, due to the lack of a debugger on the nRF52840 dongle there are a few significant differences. You need to make changes to accompany those.
• If you want something that works out of the box as a debug/test too, then buying a DK is a better approach. That solution is more mature and simpler due to the onboard debugger. The nrf52840 dongle is just released and software support is not yet fully in place.
• You can use the connectivity firmware with the patch files from the pc-ble-driver for the nRF52840 dongle directly (), so that you do not have to write any firmware yourself. But you must make sure to use the proper connectivity firmware as indicated above, and you must use the corresponding pc-ble-driver version. You cannot mix and match different versions as there are API differences between the SoftDevice versions, and HW differences between the various nRF boards (particularly the lack of a debugger means that the nRF52840 dongle is a bit tedious to work with).
• I mentioned nrfjprog, but you will have to connect an external debugger in order to use it (as there i no onboard debugger).

 

[EdwinP]

Really, my one question, which I don't yet seem to have an answer to, is exactly how do I write a PC program to use the nRF dongle?

Here's what I think I understand.  Please verify if I have this correct.

1. Since nrfutil seems to require sd-req code 0x8C, it appears I have SoftDevice s132_nrf52_3.0.0 loaded into my dongle by nRF Connect when I run Bluetooth Low Energy.  nRF Connect also loads a ble_connectivity app, but I don't know the exact source code or hex file for it.

2. To put a different version of SoftDevice into the dongle, I need to use the dev board or a segger to program it through P1.  I cannot use DFU for this.

3. The directory nRF5_SDK_15.0.0_a53641a\examples\connectivity\ble_connectivity\hex contains only this one hex file for the pca10059 (the nRF52840 dongle I have): ble_connectivity_s140_usb_hci_pca10059.hex

4. The PC code to interface to the connectivity app is pc-ble-driver-master, which only has versions to link with s130 v2.0.1 and s132 v5.0.0.  I need to modify this code to link with s140 to use it with the dongle and the above hex file.  Or, I need to modify it to use s132 3.0.0 instead of s132 5.0.x and hope it is compatible with the connectivity application loaded by the Bluetooth Low Energy app.

5. I am able to compile ble_connectivity with SD_API_VER  and NRF_SD_BLE_API_VERSION set to 5.  If I set these to 3, the code has compilation errors.

6. I could not find a file for download named s132_nrf52_5.0.0_softdevice.hex.  I did find s132_nrf52_5.1.0_softdevice.hex.  I don't know if this is compatible with 5.0.0.

7. If I manage to load connectivity_2.0.1_1m_with_s132_5.0.hex along with s132_nrf52_5.1.0_softdevice.hex maybe I can expect the hrm_v5 application to function?

8. Instead, I could try to modify the hrm_v5 example to sork with s140, and program the dongle through P1.  I am not sure if this programming procedure is dont twice (once for SoftDevice and once for the app), or if I use mergehex to make one hex file to program.  Or, if I also need to include some code for MBR.

9. I compiled the source code for

nRF5_SDK_15.0.0_a53641a\examples\connectivity\ble_connectivity\pca10059\ser_s140_usb_hci

which produced nrf52840_xxaa.hex, 193 kb.  That distribution also included s140_nrf52_6.1.0_softdevice.hex, 423 kb.  If I use mergehex to combine these, the combined file is 615 kb, but the included hex file ble_connectivity_s140_usb_hci_pca10059.hex is only 607 kb.  I think this means that the code I compiled is different from the distributed hex file.  Any idea why?

[Einar Thorsrud]

Hi,

1. Yes, that seems correct.

2. No, you can use DFU with nrfutil to program the SoftDevice as well. You will soon be able to use the Programmer app for nRF Connect for Desktop as well, but the current pre-release does not work properly.

3. ?

4. You cannot use the pc-ble-driver master branch, as this does not have support for the nRF52840 dongle. the firmware uses the UART peripheral of the nR52832 DK, via the onboard SEGGER debugger which is not present on the nRF52840 dongle. There is absolutely no way this firmware can work on the nRF52840 dongle (the UART pins that are used are not connected to the PC in any way).

5. You need to build the connectivity firmware with the patches from the pc-ble-driver branch that has support for it (see previous post). The pc-ble-driver documentation describes how to apply the patches.

6. You should not use any of the S132.... SoftDevices or projects. You need the connectivity firmware for the nRF52840 dongle, which uses the S140 SoftDevice.

7. No, you cannot expect anything to work as you are not using firmware on the nRF that use the USB in any way. It is effectively not connected to your computer.

8. Yes.

9. The size difference could be caused by you not having used the same toolchain as was used to make the precompiled .hex and/or using a different optimization level. (You would also see a difference in size if you enable/disable features such as logging)