NRF connect debugger stuck on arm reset.s

[DanZ]

Hello,

I am new to embedded programming and I'm trying to create a small application that uses BT advertisements.
I've tested my code on an NRF52840 dongle, and a board with an NRF52810 chip.

In a few cases, when trying to debug my code on either a board with an NRF52810 or an NRF52832, the debugger breaks immediately on \v2.0.0\zephyr\arch\arm\core\aarch32\cortex_m\reset.S

Trying to step over or continue just leads the debugger to hang, and it seems like the application doesn't continue to run.

With the NRF52810, just trying again the next day suddenly worked. I'm not able to get the NRF52832 working though.
Could this be a hardware issue (I've had some of these boards laying around for a while)? Or is it some other problem with my setup?

Thanks for your help!

[DanZ]

I'll add that I'm debugging via a NRF52 DK using P20. I think the setup and the wiring itself is ok, since this does seem to work against some of the boards that I have.

[Einar Thorsrud]

Hi,

It could be interesting to see the call stack, but could this be that the device restes due to an error as the default error handler triggers a reset? Can you test with CONFIG_RESET_ON_FATAL_ERROR=n? Also, as you mention stepping and Bluetooth, please note that the Bluetooth stack will most often trigger an assert if you step in the code or contine from a breakpoint when Bluetooth is enabled.

[DanZ]

Hey,

Thanks for the reply.
The call stack is empty, just z_arm_reset().
I am expecting it to break on the enterance to main, before BT is enabled.

The code breaks in the same place, even when compiling with: CONFIG_RESET_ON_FATAL_ERROR=n

[DanZ]

Adding extra info: 

Registers:

-exec info registers
r0 0x0 0
r1 0x0 0
r2 0x0 0
r3 0x0 0
r4 0x0 0
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20003aa0 0x20003aa0 <z_main_stack+1024>
lr 0xffffffff -1
pc 0xe6ac 0xe6ac <z_arm_reset>
xpsr 0x1000000 16777216
fpscr 0x0 0
msp 0x20003aa0 0x20003aa0 <z_main_stack+1024>
psp 0x0 0x0 <internal_rand>
primask 0x0 0
basepri 0x0 0
faultmask 0x0 0
control 0x0 0
apsr 0x0 0
epsr 0x1000000 16777216
ipsr 0x0 0
iapsr 0x0 0
eapsr 0x1000000 16777216
iepsr 0x1000000 16777216

Threads:

-exec info threads

Id Target Id Frame * 1 Thread 57005 (Unknown thread) z_arm_reset () at C:/ncs/v2.0.0/zephyr/arch/arm/core/aarch32/cortex_m\reset.S:68

-exec info fun main

All functions matching regular expression "main": File ../src/main.c: 43: void main(void); File C:/ncs/v2.0.0/zephyr/arch/arm/core/aarch32/thread.c: 519: void arch_switch_to_main_thread(struct k_thread *, char *, k_thread_entry_t); File C:/ncs/v2.0.0/zephyr/kernel/init.c: 197: static void bg_thread_main(void *, void *, void *); 348: static void switch_to_main_thread(char *); File C:/ncs/v2.0.0/zephyr/kernel/timeout.c: 183: k_ticks_t z_timeout_remaining(const struct _timeout *); File C:/ncs/v2.0.0/zephyr/kernel/work.c: 580: static void work_queue_main(void *, void *, void *);

[Einar Thorsrud]

Hi,

I see. Can you share more about the board you are running on (perhaps share the schematics)? Also, which SDK version are you using? And lastly, does your firmware run on a DK (if you have that available)?

A few common pitfalls when running on custom HW is if that does not have the 32.768 kHz oscillator or DCDC inductors, and either of those are enabled. So I would start by disabling those by adding this to prj.conf or similar:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

CONFIG_BOARD_ENABLE_DCDC=n