nrf52840 hitting unknown breakpoints

[SwitchGM]

Hello all,

I am trying to prove that I can compile and upload some simple code that I have written and run it successfully on an nrf52840. 

I'm using an mdbt50q-db-40 development board from Raytac, a raspberry pi 3 and openocd to flash the mcu over swd, and platformio (arduino framework) as an ide to write and compile the code.

So far, I have been successful with flashing premade a bootloader that lets me upload code over the usb interface.

However, I am struggling to get some simple code of my own to run.

(In this instance, I am not using any bootloader, I am under the impression that this is not necessary if I am not using the usb/dfu, etc features?)

#include <Arduino.h>

void setup() {
  // put your setup code here, to run once:
}

void loop() {
  // put your main code here, to run repeatedly:
}

I seem to be able to upload the code without issue, however when trying to get it to run, openocd spits out this.

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

I don't believe that I have set any breakpoints or similar. 

I have also tried a simple blink script, but haven't observed any movement on any of the nrf52840 pins when disconnected from the swd interface.

I'm aware that this question is probably better suited to the openocd community, but I'm hoping to get some insight from you guys!

Thanks for all the help,

Joe

[iforce2d]

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... :(

[iforce2d]

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

[Vidar Berg]

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.

4555.blinky_pca10040.hex

[iforce2d]

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...

[iforce2d]

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.

[iforce2d]

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...

[Vidar Berg]

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)