ISP1807 (nRF52840) – Bootloader + Arduino app does not run on custom board, but works when hex is copied from a working board

Projects Programming
1

Hi,

I’m having trouble getting an ISP1807 (nRF52840) to run on a custom PCB, and I’m hoping someone here might recognize what I’m missing.

Hardware / setup

J-Link connection, power, and basic wiring are confirmed to be OK.

What I want to do

  • Write applications using Arduino IDE
  • Flash the compiled hex using J-Link / nRF Connect Programmer
  • Use SEGGER RTT for debug logs
  • RTT should keep working after reset or power cycle
  • The application itself is simple:
    • control a few SPI devices
    • basic BLE communication

Bootloader

I am using the bootloader provided on the Switch Science ISP1807 breakout board product page (link above).
I am not using any other third-party bootloaders.

Problem

Custom board: nothing runs

On my custom PCB, I tried flashing:

  • the Switch Science bootloader
  • an application hex built with Arduino IDE

using J-Link / nRF Connect Programmer.

Result:

  • LED on P0.06 never turns on
  • No visible sign that the MCU is running code

The LED and power wiring are fine (the LED lights if I pull the MCU pin to GND manually).

Breakout board: works fine

The same Arduino sketch, when written to the Switch Science breakout board via Arduino IDE, works perfectly:

  • application runs
  • RTT output works as expected

Manually flashing bootloader + app still fails

Even when I use:

  • the Switch Science bootloader
  • the exact same Arduino-built application hex

and flash both manually to the custom board, it still does not run.

but.

Arduino IDE → breakout board → extract hex → custom board → works

If I:

  • Write the sketch to the Switch Science breakout board using Arduino IDE
  • Use nRF Connect Programmer to save the full flash contents as a hex file
  • Flash that hex file to my custom board

→ the application runs correctly on the custom board.

So the hardware itself seems OK.
It looks like there is some difference between:

  • “bootloader + app flashed manually”
  • and “a full flash image that originally came from Arduino IDE”

Questions

  • On ISP1807 / nRF52840, are there any common reasons why:
    • manually flashing a known-good bootloader + Arduino app does not run
    • but copying a hex from a working board does run?
  • When using Arduino as the development environment, what is the recommended way to:
    • flash with J-Link
    • use RTT reliably
    • keep things working after reset and power cycling?
  • If this cannot be solved by simply flashing “bootloader + app”:
    • is it technically possible to reuse or reconstruct a bootloader-equivalent state based on a known-good board?
    • for example, reusing everything except the application area, or using the working image as a baseline
    • are there any major pitfalls or things I should be careful about?

This is purely for personal, non-commercial hobby use.
I’m just trying to avoid throwing away a custom PCB that took a lot of time and money to make.

Sorry if my English is strange — I used a translation tool.
Please let me know if anything is unclear or incorrectly written.

Thanks in advance for any advice or hints.

2

The best thing you can do to get help is post an annotated schematic showing all connections, power, ground, power sources and note any lead over 25cm/10".

Post links to the technical information on each of the hardware devices.

3

Thanks for the reply.
As suggested, I’ve attached a simplified schematic (PNG).
Some details are not explicitly annotated in the schematic, so I’d like to clarify them below.

The schematic diagram is as follows:

Sc
Sc1920×863 159 KB

Wiring / Power

  • All connections are on a single PCB.
    No long flying leads or jumper wires are used; SWD and RESET traces are only a few centimeters.
  • 3V3 pin is supplied with 3.3 V.
  • GND is connected to the board ground.
  • 5V is not connected.
  • Power is supplied from an external switching power supply.

RESET

  • RESET is wired to P0.18.
  • At the moment, I am not using the configuration that permanently enables the RESET pin in firmware.
  • During experiments, after doing erase all, I once enabled the RESET pin configuration and pressed the reset button.
    After that, recovery required another erase all, so in my recent tests I have been avoiding this setting.

SWD

  • SWDIO / SWCLK are connected to the standard nRF52840 SWD pins.
  • J-Link connection, flashing, and read-back all work without issues.

LED

  • LEDs are connected to P0.15 and P0.04.
  • With the working hex (copied from the breakout board), these LEDs light correctly.
  • The LEDs also light when the pins are manually pulled to GND, so the LED wiring and power look OK.

Important isolation result

  • On the same custom PCB and same power conditions:
    • If I flash a hex copied from a working breakout board, the application runs correctly.
    • If I manually flash the bootloader + Arduino-built application, it does not start.
  • When flashing manually, I use nRF Connect Programmer and always run erase all

before programming.

I will also include links to the main documents I am using below.

Reference documents:

Please let me know if there is other information I should provide or anything specific I should check next.

(Sorry if my English is a bit awkward — I’m using a translation tool.)

4

Your ISP1807-LR-RSIP1807-LR-RS

Going through the data sheet and many other sources I found It points to a power supply problem. Recommended external bypassing (typical good practice for this kind of RF MCU module):

  • 1x bulk cap: 4.7 uF to 10 uF ceramic from VCC_nRF to GND
  • 1x HF cap: 0.1 uF (100 nF) ceramic from VCC_nRF to GND

Placement rules:

  • Put the 0.1 uF as close as physically possible to the VCC_nRF pin and a ground via (same side, tiny loop).
  • Put the 4.7 to 10 uF right next to it (still close, but it can be a few mm farther than the 0.1 uF).

If your 3.3 V rail is shared with motors, switching regulators, relays, LCD backlights, etc., add one of these:

Option: Ferrite bead feed for the module rail

  • 3.3 V rail -> ferrite bead -> VCC_nRF (module)
  • Caps (0.1 uF + 4.7/10 uF) on the module side of the bead

Layout checklist (this matters as much as the values)

  • Do not run VCC_nRF through a long skinny trace; use a short, wide trace or a small pour.
  • Put at least one dedicated ground via right beside each bypass capacitor ground pad.
  • Keep the bypass loop tiny: VCC pin -> cap -> ground via -> ground plane -> back to module ground.
  • Give the module a solid ground plane under/around it as allowed by the datasheet layout guidance; RF modules hate split grounds.

Here is A practical "works most of the time" starting point

  • At VCC_nRF pin area:
    • Cx1 = 0.1 uF X7R 0402 (or 0603 if you like), to GND
    • Cx2 = 10 uF X5R/X7R 0603/0805, to GND
  • If VBUS used:
    • Cx3 = 0.1 uF to GND at module VBUS
    • Cx4 = 1 uF to 4.7 uF to GND near USB connector

Please remember that I do not have this board or anything similar, so I cannot validate what is stated above. I was curious about your problem and spent several hours reading and searching the web. The information above is what I believe may help you.

5

Thanks for taking the time to look into this and for the detailed advice.
I understand that power decoupling and layout are very important for RF MCUs, and your concrete examples are helpful.

To clarify the actual board configuration, I’d like to add the following details.

  • On the PCB, VCC_nRF and GND are not split; they are implemented as a single, continuous plane.
  • No noise-generating loads such as motors, relays, or backlights are connected to VCC_nRF.
  • For the ISP1807 (nRF52840), as well as for the connected sensors, decoupling capacitors are placed at each power pin according to the respective datasheets.

There is also an isolation result that seems important in this case.

  • On the same custom PCB, with the same power supply and wiring:
    • If I flash a full flash image (hex) copied from a working breakout board programmed via Arduino IDE, the system boots and runs correctly.
    • If I manually flash the Switch Science bootloader together with an Arduino-built application, the system does not start.

Because of this, I suspect that the issue may be related more to differences in flash layout or boot conditions expected by the bootloader, rather than a fundamentally insufficient power supply.

That said, I will review the power margins and decoupling again as you suggested.
If you have any ideas regarding bootloader assumptions, application placement, or startup conditions that might explain this behavior, I would really appreciate your insight.

Thanks again for your help.

6

I’ve identified the root cause of the issue.

The problem was that I had not set the bootloader start address in UICR, so the CPU never jumped to the bootloader or the application. As a result, execution never reached my own code at all.

Once the bootloader address was correctly configured in UICR and execution was able to reach my application code, I confirmed that:

  • The application starts normally.
  • Protection features behave as expected.
  • RESET pin configuration works correctly.
  • Even after reset or power cycling, SWD access from outside remains available.

In other words, while execution was not reaching my code, all protection and reset behavior appeared to be incorrect, but the actual root cause was simply the missing UICR configuration.

Thanks to everyone for the advice and suggestions. They helped me step back and re-check the fundamentals.
I hope this summary is useful for anyone who might run into a similar issue.