Difficulty with mcuboot and nRF52840, can't leave bootloader mode

Hi all,
I’m using the Legacy Notecard Cellular on a Notecarrier-F, with an Adafruit nRF52840 Feather Express, developing with Nordic’s nRF Connect SDK in Visual Studio Code.

I’m trying to get outboard DFU working, and am running into a problem where the board just goes into DFU mode all the time and will never run app code.

Figuring I must be overlooking something, I decided to just try to get this example project working, straight out of git:

I’m seeing the same symptom with this example as I was with my own codebase: I create a project from this example (using the blinky fast one, specifically), build it and flash it to my board no problem. But once I have flashed it, the solid red LED on the Feather seems to indicate that it’s in bootloader mode. We’re not getting any of that sweet blinky action, I think because we’re not actually running the application code and are instead going right into bootloader mode every time. Here are some things I have tried that haven’t worked:

  • Press the reset button on the Feather (goes right back to same state, red LED)
  • Press the user sw button on the Feather (nothing happens)
  • Press the reset button on the Feather while holding down the user sw button on the Feather (goes right back to same state)
  • Connect the Feather’s D2 pin to 3v3 while pressing the reset switch on the Feather
  • Connect the Feather’s D2 pin to GND while pressing the reset switch on the Feather
  • Uncommenting CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y in the mcuboot.conf, rebuilding and reflashing.
  • Commenting it back out, rebuilding and reflashing…
  • Check the Feather’s D2 pin with a DMM (3.3v)

On the forums here there is another post describing what seems like exactly the same symptom, but it doesn’t appear to have reached a resolution:

Does outboard DFU still work for the nRF52840? Am I missing something obvious?

Here’s a photo, in case that’s helpful:

Hi @scase

Welcome to the Blues community! It’s great that you are trying this with the blinky example, as it will help us get to the bottom of the issue quicker. Although I don’t have an Adafruit nRF52840 feather, I tested ODFU with an nRF52840 devkit and it worked for me without an issue. I’ll try and order an nRF52840 feather so that we have an identical setup.

In the meantime, we can troubleshoot a few things to see why this issue is happening on your end. From your description, it seems that the app never runs and that you’re stuck in the bootloader. Does this happen even when the feather board is removed from the Notecarrier F? Try powering off the board, removing it from the Notecarrier, and then powering it up again independently.

If the nRF52840 never enters the app mode regardless of its connection to the Notecarrier, then this indicates that it is an nRF52840 issue. You may need to fully erase the feather through the command “nrfjprog --eraseall” (you will need a Segger J-Link for this). Please be aware that this will erase the entire flash, including any pre-loaded bootloader, but this shouldn’t be an issue as you’ll flash the MCUBoot bootloader afterwards. Once erased, try rebuilding the blinky application and loading it via “west flash” as described in the blues guide.

If the nRF52840 gets stuck only when connected to the Notecarrier F, then this indicates that it’s not an nRF52840 issue. Can you please double check that the DFU dip switch is set to ON? You can also entirely remove the feather and make the following direct connections (this is what I did to test this with the nRF52840 devkit):-

  • Connect AUX4 to the reset pin.
  • Connect AUX3 to the boot pin (for the Blues example, this is GPIO 10).
  • Connect AUX_TX to the feather’s RX line.
  • Connect AUX_RX to the feather’s TX line.
  • Connect GND to the feather’s GND.

Refer to the wiring guide for detailed instructions. Using a breadboard can help simplify the connections between the Notecarrier and the feather board.

Let me know if these suggestions help and if you manage to make any progress with this issue.


1 Like

Thank you for the help, Youssif. I worked through your email and report results below.

Regarding hardware: I do also have an nRF52840-DK development board, which may be the same as the board you were using previously? We could troubleshoot on this board, if that would be easier for you.

If I unplug the Feather from USB (which is its power source), then remove it from the Notecarrier-F, then plug it back in, I observe the behavior is the same even when it’s not on the Notecarrier, implying the issue is on the nRF52840 side.

Next, I performed the erase you suggested (nrfjprog --eraseall) using the J-Link, and reprogrammed the Feather. Here is what I was able to determine:

If I erase the Feather, then remove power from it, then plug it back in and program it with Blinky, the Blinky code runs and blinks the LED… but upon the next boot-up, it goes immediately to bootloader mode and won’t boot normally. In other words it will run the blinky code only until I press reset or remove power and plug it back in. If I do either of those things, it is back to permanent bootloader mode. Also interesting: If I erase it and the immediately reprogram it without first removing power briefly, it immediately goes to bootloader mode.

Yes, the DFU switch on my Notecarrier is set to ON. I checked it again to make sure. The Feather Power switch is also set to ON.

Next I flashed the Blinky example to my nRF52840-DK (Nordic dev kit). (I made a new build configuration for the -DK, instead of the Feather.) It immediately lights LED1 steadily. No LEDs blink at all, even when it has been freshly erased and programmed. I have not connected this board to the Notecarrier, as it seems like the problem is not really related to the carrier, but I can do so if it would be helpful.

I wonder if this could be related to the version of NCS? I am building under nRF Connect SDK version 2.6.1. If you are using a different version, I could try the same one.

Below is an image of the Nordic board I have:

1 Like

I’m also using version 2.6.1, so we’re on the same setup, which is great for troubleshooting. I recommend continuing to test with the nRF52840 DVK until we get to the bottom of this. The good news is that we’ve confirmed this is an issue specific to the nRF52840, so we can narrow down the potential cause.

Currently, what happens when you try to reset the nRF board using the reset button? If it still doesn’t boot into the Blinky app, try the following:

  • Erase the flash fully using “nrfjprog --eraseall”.
  • In your “prj.conf” file, comment out the line “CONFIG_BOOTLOADER_MCUBOOT=y” or set it to “n” to disable mcuboot.
  • Rebuild and flash the app again onto the nRF52840 devkit using west.

If the reset button works normally after this, the issue may be with the MCUBoot bootloader, possibly due to a configuration problem. If the issue persists, then we might be missing something else. Other things to check include ensuring the devkit is receiving enough power (i.e., not powered from a USB hub). Additionally, you can try connecting GND to pin 0.18 for a few seconds to see if this resets the board.

By the way, I also suggest checking the Nordic forum to see if anyone has encountered a similar issue in the past.

Hi Youssif,
If I press the reset button on the DK, LED1 goes out for however long I have the reset button held down, then comes back on solid when I release reset.

  • Next I erase the board with nrfjprog. The command reports success, and LED1 goes off. So at this point, I have the power LED on the DK board lit solid, and no other LED is lit.
  • I power the board off and back on via the power switch now, just to be sure.
  • I comment out the mcuboot line in the prj.conf. (This means the only thing left in my prj.conf is the line “CONFIG_GPIO=y”.) I build again and the build completes successfully.
  • After I flash this new build to the board, LED1 begins blinking. If I press reset, the LED goes out briefly but resumes blinking quickly after I release the button.

I agree with your conclusion that this indicates there is likely a problem with mcuboot or its configuration, or perhaps with the configuration of the GPIO that is used to trigger bootloader mode.

I did check the Nordic Devzone for similar issues. I found one post that seemed potentially relevant, however it is more than two years old. To summarize, a user reported that the bootloader may poll the GPIO too quickly after the pin has been configured, causing a false positive reading. He found that he could solve this problem by inserting a short delay in the bootloader code. I looked at the file he modified (\nRF_Connect\v2.6.1\bootloader\mcuboot\boot\zephyr\main.c), and I see that since the time of his post, it seems like mcuboot has become more robust. The current version does a number of checks to ensure that the GPIO is ready and to debounce it. I suspect that if the problem is here in the bootloader code, it would probably take more than a simple to delay to resolve it this time. I’m hoping the issue is some simple config thing I have missed. I’m going to try to do some digging in that direction.

Does the blinky example work properly for you on the same hardware?

Thank you again, Youssif, for helping me with this problem. I appreciate your methodical and thorough approach to troubleshooting.


1 Like

Hey @scase, can you try modifying the mcuboot.overlay file so that it uses a different GPIO (e.g. gpio0 24 instead of gpio0 10). I checked the devkit datasheet and pins 0.9 and 0.10 are used by NFC on the devkit, so it’s better/safer to use another pin for MCUBoot. This shouldn’t be the case for the nRF52840 feather, but it’s worth experimenting with changing this there too. Please make sure to completely delete the “build” directory before rebuilding the project, and fully erase the devkit before using “west flash”.

If this still doesn’t resolve the problem, I recommend reaching out to Nordic support for further assistance, as they are more equipped to handle issues specific to the nRF52840 or NCS.


I believe you called it correctly here! I tried what you suggested on the DK, and it works. One of the pushbuttons becomes the DFU signal, so you can reset while pressing that button to get into DFU mode, but otherwise, you get blinky.

I started looking more closely and found that this is also true on the Feather. That pin down in the corner that the Notecard wants to use for DFU is the same one, and by default the 52840 uses it for NFC. It CAN be used as a regular GPIO, but you do have to tell it you want to do so.

You can do this by including the following in the devicetree. I added this into the mcuboot.overlay at the bottom, outside of the root context. I would suggest adding this to your github project’s overlay.

&uicr {




Thanks for all of your help on this!