nrf52840 hitting unknown breakpoints

RE: nrf52840 hitting unknown breakpoints

Vidar Berg — Fri, 02 Oct 2026 12:01:07 GMT

I'm glad to hear you were able to identify the problem, and thank you for taking the time to report back. Regarding the hex file I sent, I mistakenly built it for the PCA10040 (nRF52 DK) as I thought you were using the nRF52832 for some reason but that turned out to be fine for this basic sample.

( Ref. https://docs.nordicsemi.com/r/bundle/nrf5_sdk_v17.1.0/page/sdk_for_custom_boards.html)

RE: nrf52840 hitting unknown breakpoints

iforce2d — Fri, 02 Oct 2026 11:14:11 GMT

I discovered the problem with being unable to run after flashing via OpenOCD on Raspberry Pi. In my .cfg file I had "reset_config srst_only srst_push_pull" which I think might have been expecting to restart only by a physical wire between the Pi and the nRF52840. I did have that wire connected occasionally but perhaps that setting was still not appropriate. After removing that line it now flashes and runs just fine, so the contents of my .cfg is:

adapter driver bcm2835gpio
transport select swd
adapter gpio swdio 23
adapter gpio swclk 24
source [find target/nrf52.cfg]

Hope this helps someone...

RE: nrf52840 hitting unknown breakpoints

iforce2d — Fri, 02 Oct 2026 02:51:56 GMT

Ok, I think I have sorted this out now. I noticed that even though OpenOCD on the RPi got stuck after flashing my program, it would run fine after a full power-off reset.

The reason it took me so long to notice that, is because I had been disconnecting the VCC pin to do a power-off reset, but apparently there is still enough power from either DIO or CLK that it doesn't reset at all! Just by chance one time I disconnected GND instead to do the reset which actually does caus a reset.

After that, I moved back to using a ST-Link dongle from my main desktop computer which is what I wanted to do in the first place, and that works fine - program, verify, reset causes the program to start every time without any problems, and debugging works fine. I should have just tried that earlier, but after the APPROTECT problem with the ST-Link dongle I thought the RPi would be more dependable so I wanted to get everything working there first.

In hindsight, all I had to do was use the RPi just once to run nrf52_recover, and then go straight back to the ST-Link dongle. But it ended up being a perfect storm of overlapping problems all taking their turn to rob me of two days of my life, namely:

- didn't realize the OpenOCD message "nRF52 device has a CTRL-AP dedicated to recover the device from AP lock. Do not enable UICR APPROTECT" is only a general warning, it doesn't mean debugging is blocked right now

- didn't realize P0.14 and P0.16 were connected to nRESET

- didn't realize disconnecting only VCC was not actually causing a reset

One thing I still can't explain is why Vidar's hex would start ok from the RPi but mine wouldn't.

Anyway, now I am back to the IDE and dongle I prefer, I have s113 soft device and ble_app_uart running nicely. Thanks for your time.

RE: nrf52840 hitting unknown breakpoints

iforce2d — Thu, 01 Oct 2026 12:42:29 GMT

Thanks for the reply. With your hex file it seems to work fine, and if I only flash yours repeatedly it starts up nicely every time.

Example of flashing yours:

> halt
[nrf52.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x00000742 msp: 0x2000fff8
> program /home/pi/nrf/4555.blinky_pca10040.hex verify
[nrf52.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x00000742 msp: 0x2000fff8
** Programming Started **
Adding extra erase range, 0x00000760 .. 0x00000fff
** Programming Finished **
** Verify Started **
** Verified OK **
> reset
[nrf52.cpu] halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x2000fff8
> resume ( <-- blinky runs ok here )

Example of flashing mine:

> halt
[nrf52.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x00000742 msp: 0x2000fff8
> program /home/pi/nrf/nrf52832_xxaa.hex verify       
[nrf52.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x00000742 msp: 0x2000fff8
** Programming Started **
Adding extra erase range, 0x00000888 .. 0x00000fff
** Programming Finished **
** Verify Started **
** Verified OK **
> reset
[nrf52.cpu] halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x2000fff8
> resume
[nrf52.cpu] clearing lockup after double fault
[nrf52.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x21000000 pc: 0x00000472 msp: 0x20040000
[nrf52.cpu] Polling failed, trying to reexamine
[nrf52.cpu] Cortex-M4 r0p1 processor detected
[nrf52.cpu] target has 6 breakpoints, 4 watchpoints
[nrf52.cpu] Examination succeed

(at this point, reset and resume both continue to give the same result as above)

I notice your file name has pca10040 rather than pca10056 so I tried building for pca10040, but same result.

So it would seem like my build is just messed up somehow. I will try with some other toolchain I guess...

RE: nrf52840 hitting unknown breakpoints

Vidar Berg — Thu, 01 Oct 2026 11:03:32 GMT

I don't have an OpenOCD programmer here to test with (we officially support JLink debuggers), but to help narrow down the problem, please try flashing the attached hex file. It is built from the same Blinky project modified to only toggle P0.15.

devzone.nordicsemi.com/.../4555.blinky_5F00_pca10040.hex

RE: nrf52840 hitting unknown breakpoints

iforce2d — Thu, 01 Oct 2026 10:23:56 GMT

Schematic for this board is here: https://nicekeyboards.com/docs/nice-nano/pinout-schematic/

There is an LED on P0.15 which I tried (excluding all other LEDs). With that program in place, occasionally the LED does light up at the moment I do a 'resume' after programming, but it doesn't get a chance to actually blink. One time after taking a break for a day to regain some sanity, I powered the board up and it actually ran normally, blinking as expected! Have not been able to reproduce it though. On another occasion, the LED lit up when I connected the reset pin to the RPi (needed for nrf52_recover).

RE: nrf52840 hitting unknown breakpoints

iforce2d — Thu, 01 Oct 2026 10:05:27 GMT

I am having almost exactly the same problem. My board is a Nice Nano, I think (or maybe a clone of that). Steps I took are as below.

On build machine, Fedora Linux desktop:

- download the nRF5 SDK, version 17.1.1, extract from zip

- edit components/toolchain/gcc/Makefile.posix to set my toolchain's bin folder (using toolchain from STM32CubeIDE)

- edit examples/peripheral/blinky/main.c so that it does nothing, ie. while(true) {}

- in examples/peripheral/blinky/pca10056/blank/armgcc run make, builds ok

- flash using OpenOCD and ST-Link dongle, struggle for many hours with APPROTECT

- give up and copy .hex file to Raspberry Pi 3

On Raspberry Pi 3 with OpenOCD

- do nrf52_recover, seems to succeed ok

- program my .hex file, seems to program and verify ok

- strike (mostly) same issue as OP describes above

> program /home/pi/nrf/nrf52840_xxaa.hex verify
[nrf52.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0xffffffd8
** Programming Started **
Adding extra erase range, 0x00000a30 .. 0x00000fff
** Programming Finished **
** Verify Started **
** Verified OK **

> reset run
[nrf52.cpu] halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0xffffffd8

> reg 
===== arm v7m registers
(0) r0 (/32): 0xcf6e2db1
(1) r1 (/32): 0x00000000
(2) r2 (/32): 0x00000000
(3) r3 (/32): 0x00000a30
(4) r4 (/32): 0x00000a30
(5) r5 (/32): 0x00000008
(6) r6 (/32): 0x04c11db7
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0x00000000
(9) r9 (/32): 0x00000000
(10) r10 (/32): 0x00000000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x00000000
(13) sp (/32): 0xffffffd8
(14) lr (/32): 0xfffffff9
(15) pc (/32): 0x2000002e
(16) xpsr (/32): 0x61000000
(17) msp (/32): 0xffffffd8
(18) psp (/32): 0x00000000
(20) primask (/1): 0x01
(21) basepri (/8): 0x00
(22) faultmask (/1): 0x00
(23) control (/3): 0x00

I checked that LR with addr2line but it just gives me a question mark for the 0xfffffff9 address, understandably.

The reason I edited main() to do nothing is because apparently this board has P0.14, P0.16 and P0.18 (nRESET) all connected together for some reason, and the blinky would toggle 14 and 16 which probably gave me another few hours of grief before I realized. Been at this for 2 days, never had such a hard time simply blinking an LED. I have worked with nRF51822 in the past and everything was super easy... :(

RE: nrf52840 hitting unknown breakpoints

SwitchGM — Thu, 23 Oct 2025 11:41:46 GMT

Hey Vidar,

Thank you very much for the response!

Surprisingly, I'm no longer experiencing the break point issue.

I'm not sure why this no longer occurs, but I will update the ticket with any information I find 🙂

Thank you for the help. (processor core registers was new to me and a very interesting read!)

Kind regards,

Joe

RE: nrf52840 hitting unknown breakpoints

Vidar Berg — Wed, 22 Oct 2025 12:16:33 GMT

Hello Joe,

Unfortunately, I don't have experience with this framework or debugger and I'm afraid I don't have an explanation for why this breakpoint is set either. But it's interesting that it appears to be set at a RAM address. Most applications don't execute code from RAM.

Can you run the 'reg' command after the breakpoint has been hit and check which address register r14/lr points to (https://developer.arm.com/documentation/ddi0439/b/Programmers-Model/Processor-core-register-summary). You can use addr2line from the command line to look up the LR address in your .elf/.out file (assuming this is included in your build output).

Best regards,

Vidar