nrf52840 hitting unknown breakpoints

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

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

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

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

  • 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

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

Related