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]

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

[the_reza]

I'm using the VS Code gui and click on the flash button.  I have 2 nRF52 DK boards.  One is still in the 'virgin' state and the other has had some writes to the NV memory.  The virgin one still has this fault.  In digging through all the functions, the call it dies at is mpsl_timeslot_request(). 

I did some googling and came across one account of the identical issue:  RE: Halt on nvs_init() 

The stack trace of the issue is (btw, is there a way to copy this content as text from VS Code?)

with it faulting on the call to mpsl_timeslot_request() on line 179

Here is what's in memory at the time:

When I try running it on my non-virgin DK with some NV writes - it never hits that line of code.  

I went through to see what changed in the calling stack, and it never calls nvs_add_gc_done_ate(fs) on line 901 of nvs.c

end:
	/* If the sector is empty add a gc done ate to avoid having insufficient
	 * space when doing gc.
	 */
	if ((!rc) && ((fs->ate_wra & ADDR_OFFS_MASK) ==
		      (fs->sector_size - 2 * ate_size))) {

		rc = nvs_add_gc_done_ate(fs);
	}
	k_mutex_unlock(&fs->nvs_lock);

here are the variables  at that time

Hope that helps,

Reza

[Sigurd Hellesvik]

Hi Reza,

Thanks for the debug information, it is for sure helpful!

Can you try one more thing?

For the "virgin" board, can you try to flash it using the "Erase and Flash" and see if it still gets the error?

Regards,
Sigurd Hellesvik