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

[Vidar Berg]

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

[SwitchGM]

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

[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