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?

[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)

[EdwinP]

As far as I can tell some of your answers do not seem right to me.

The pc-ble-driver project is a program that can be compiled on Windows, not a firmware project.  As I mentioned, I need to write PC code to talk to the dongle.  I understand that the ble_app_uart project is firmware that runs on one of your parts, but not the dongle because the UART would need to be replaced with a USB interface.  I am not talking about that.  The pc-ble-driver branch does contain some hex files for various versions of SoftDevice and connectivity apps, but not something that runs on the Dongle without modification.  The nRF5_SDK_15.0.0_a53641a branch contains an example under connectivity\ble_connectivity\pca10059\ser_s140_usb_hci, which I would expect to be hex code I should be able to use to talk to the dongle.  The PC side of that communication should be some modification of the PC code in pc-ble-driver.  Is that not correct?

Since I have ble_connectivity_s140_usb_hci_pca10059.hex which is pre-build firmware for connectivity to the dongle using USB, can I just load that into the dongle?  I should just need to update pc-ble-driver on the PC to match the version of SoftDevice used.  I don't know how hard that is.

Is this clear?  I need to verify which hex file to load into the dongle and what changes I need to make to pc-ble-driver to use s140 instead of s132.

I have tried to write ble_connectivity_s140_usb_hci_pca10059.hex to the dongle using nrfutil.  After it reports success, the dongle is still in boot loader mode on COM4, and the experimental programmer app reports that only the boot loader is loaded.  I have not found any way to program the combined file ble_connectivity_s140_usb_hci_pca10059.hex into the dongle or to change the SoftDevice loaded to s140_nrf52_6.1.0_softdevice.hex.  How do I do it?

[Einar Thorsrud]

Hi,

I think we are talking about the same thing. I checked with one of the the pc-ble-driver developers and he recommended that you use the v2.3.2 tag of the pc-ble-driver. You should use this version on the PC, and the connectivity firmware connectivity_6.0_1m_with_s140_usb_6.0.hex from here (same tag). This is the same version (pc-ble-driver and connectivity firmware) that will be used for the next release of nRF Connect for desktop.

[EdwinP]

This is what I was looking for!  That code works with s132_nrf52_3.1.0_softdevice.hex, not connectivity_6.0_1m_with_s140_usb_6.0.hex, but s132 v3 seems to be what nRF Connect has loaded into my dongle, so that should work.  I'll let you know if I have any more problems.  Thank you so much.

I hope in the future, you will update a branch of pc_ble_driver to support s140.