nRF52 DK - Peripheral UART example unmodified fails if CONFIG_BT_SERVICES is enabled.

[the_reza]

I'm testing out the Peripheral Uart example on the nRF52 DK with zero modifications using visual studio code.  However, when I run it, it constantly reboots.  When using the debugger, it seems to be that something in the bt_enable() function causes it to SIGTRAP.

This is the output of the debug console

Thread 9 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Remote target]
z_arm_is_synchronous_svc (esf=0x20006548 <z_main_stack+8>) at C:/ncs/v2.1.0-rc2/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:649
649 uint16_t fault_insn = *(ret_addr - 1);

The RTT doesn't display anything.  And if I use the debugger, it dies in the z_arm_is_synchronous_svc() with a null pointer.

In doing some more digging, it seems the fault occurs with bt_settings_init().  If I turn CONFIG_BT_SERVICES off, the application seems to boot fine.  

This is a new DK and I've not paired it with anything in the past.  Not sure if this is exposing a bug associated with new hardware?

[the_reza]

In digging further, it seems it fails when it tries to write to nvram in the function  z_impl_flash_write() which calls api->write().  Here are the arguments passed:

digging further down into the stack, the actual fault occurs in flash_sync_mpsl.c:179 when it calls

    ret = mpsl_timeslot_request(_context.session_id, req); 

 Any thoughts?

[the_reza]

full circle - definetly a bug.  I tried running the nvs app which ran fine - put some stuff on the nonvolatile system.  after that, i had no issues running the peripheral uart example.

SO - - how do i report this as a bug?

[Sigurd Hellesvik]

Hi,

So to try and reproduce I did the following:

nRF Connect SDK v2.1.0

Board: nRF52 DK (PCA10040) v1.1.1

Example v2.1.0/nrf/samples/bluetooth/peripheral_uart

Commands:

west build -p -b nrf52dk_nrf52832
west flash --erase

With this setup, the sample boots fine, and does not enter a reset loop.

Did I do this as you did?

Regards,
Sigurd Hellesvik

[the_reza]

I'm not sure how to reply to Sigurd Hellesvik  directly, but hopefully he'll see this here.

Did you try it on a brand new PCB that has had no other applications write to the NV memory?  After I tested out a different application that wrote to the NV memory (which worked) then tried this application again, it worked fine.  This example code goes down a different initialization path for writing BT info to NV memory if it's empty vs had data in it already.  I confirmed that it was a call in that code that caused the crash.   I'm guessing that this example wasn't tested on a new piece of hardware.

[Sigurd Hellesvik]

Hi Reza,

I ran the flash command with "--erase" which should be equivalent to running "nrfjprog --erase-all" on the board before flashing.
Now this should reset all registers to their default values, which would be 0xffff for the flash.

Did you erase-all before flashing your new nRF52DK?

Could it be that there was already pre-loaded firmware on the nRF52DK before you flashed peripheral_uart?
Such a firmware could possibly have set the flash to something which interfered with your program somehow, for example it could have locked a section.

As you can see from our nRF52-DK Getting Started, the nRF52-DK comes with firmware when you purchase it.

Regards,
Sigurd Hellesvik