Nrf52840 serial number location and port designation


I’ve recently purchased an nrf52840 usb dongle, and I’ve been unable to program it as I can’t seem to locate its serial number or port designation and I don’t see a way to use the nrfutil CLI without at least one of these… I’ve searched for device drivers to no avail. Any help would be greatly appreciated.

Edit: I used a program (USBDeview) to list the connected usb devices and their info and “serial number” and “port” are blank for the nrf52840 dongle. Several other devices do not show a serial number or port so I can’t be sure that this means anything.


Hi there,
Here is the tutorial about how to program the dongle:

Just hold the dongle’s RESET/USR button, and connect it to your computer. The Dongle will entered the bootloader mode and the RGB LED pulses RED, which means that the dongle is ready for programming.

If you want to compile your own firmware, remember to check that the CONFIG_GPIO_AS_PINRESET flag should be commented. If not, the Dongle would not enter the bootloader mode next time by holding the dongle’s RESET/USR button.


Thank you for the reply. Perhaps I am overlooking something. I am new to using nrfutil on the command line. I’m trying to use this command nrfutil dfu usb-serial -pkg ledtest.hex from the command line and I am presented with the error: Missing option “-p”/"–port". Required if “–serial-number” is not defined. I can’t seem to find either of these. Can you help?


Can you tell me what register I would find that flag? I’m not seeing it anywhere in the nrf52840 datasheet.


Just comment the CFLAGS += -DCONFIG_GPIO_AS_PINRESET in the Makefile. For example:

# C flags common to all targets
CFLAGS += -mcpu=cortex-m4
CFLAGS += -mthumb -mabi=aapcs
CFLAGS += -Wall -Werror
CFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
# keep every function in a separate section, this allows linker to discard unused ones
CFLAGS += -ffunction-sections -fdata-sections -fno-strict-aliasing
CFLAGS += -fno-builtin -fshort-enums


BTW, you should generate a package (.zip file) instead of .hex file when using nrfutil. The following command is an example:

Generate a package:

nrfutil pkg generate --hw-version 52 --sd-req 0x00 --application-version 1 --application app.hex

Then, flash the package, where /dev/cu.usbmodem1411 is the port name of the dongle on your PC:

nrfutil dfu usb_serial -pkg -p /dev/cu.usbmodem1411

Check nrfutil user guide for more details.


Thank you for clarifying. I’ll let you know what happens.


Hmm. When generating the .zip I get the following error:

“nordicsemi.dfu.intelhex.AddressOverlapError: Hex file has data overlap at address 0x0 on line 6.”

It seems to perform much of the process before throwing the error. Nothing is output.


Pls check your application’s .ld file. Your application should begin after the MBR.Here is the memory configuration:

  FLASH (rx) : ORIGIN = 0x1000, LENGTH = 0xff000
  RAM (rwx) :  ORIGIN = 0x20000008, LENGTH = 0x3fff8

You can also checkout our nRF5 SDK examples here.


Thank you for the response.
The sequence of steps that I am taking currently uses gcc to create the object file and objcopy to create the .hex file. The program in question is very simple, it turns on an LED, and doesn’t use any libraries. In this case, should I have an .ld file? What would I link my program to?


I apologize for some of these extremely basic questions. The school I graduated from didn’t provide any courses on C. Instead, I took Assembly. I’m now self-taught in C/C++; however, my C books said almost nothing about embedded programming and focused all the examples on .exe files executed on the PC. Until now, I’ve used the Arduino IDE, Atmel Studio 7, and Quartus Prime (for FPGAs), but these are all IDE’s and I thought I should learn the command line. Not as easy as I thought.


Yes. Every nRF5 SDK example needs a linker file which is used to configure memory regions.
You can checkout our examples or visit the tutorial to get started:


I seem to have hit another snag. I’m running into this error:
64-bit address 0x4b4fa300001000 out of range for Intel Hex file

I researched it a bit and found this:

Has this been addressed?

A workaround for this is to roll back to the GCC Arm toolchain version 6. Apparently newer versions display this error.


Sorry for the late reply. The latest GCC version has shown instabilities when using the Link Time Optimization feature, and using the feature is not recommended. If you want to use gcc-arm-none-eabi-7-2018-q2-update, you can update the nRF5 SDK to 15.3.0.

Thanks for your kind feedback.