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?

[droidecahedron]

Running into the same issue with SDK 2.1.2

Once a board is put into this state, I can't get it out.

I put it into this state by erasing the flash then flashing the board.

Another board which is in a working state I flash with the same example and it works just fine.

(nRF52833 DK)

I cannot run "erase board" on the peripheral uart sample or it gets stuck in this state until it gets nvs sample flashed onto it.

[OliverDOM]

Hi all,
I am using nRF52833 DK and having the same issue. The board is brand new. 

Is it planned to be fixed? 

In addition I can reproduce the workaround using the nvs example.

But still it is quite annoying.

Cheers

Oliver

[the_reza]

It's interesting how everyone else seems to have this problem except for the engineers at nordic.  Has anyone tried to run this example using the CLI only and not the GUI?  I don't think the nordic engineers use the gui... 

[Hieu]

Hi OliverDOM 

Are you using the peripheral UART sample in nRF Connect SDK (NCS) v2.1.x?

Have you tried using NCS v2.0.x? We recently observed a problem where the device enters a reset loop when running NCS 2.1.x, the nRF52833 DK, and the Peripheral UART sample.

When you say you have the same problem, does flashing the NVS sample fix it for you like it did for other people?

Hi the_reza ,

I am recently assigned to this ticket. The symptoms described here are fairly confusing for me. I am partially out of office due to health and family reason. I will return next week and go over everything carefully before following up with you.

Hieu

[OliverDOM]

Hi Hieu ,
yes I am using NCS 2.1.1. And as droidecahedron already mentioned 2.1.2 has still the same issue.

And yes, the workaround with nvs example works fine. 

Nice to hear that someone is assigned to the ticket. After all, the problem has been known for at least 2 months now. Don't get me wrong, but I am NOT working on student projects here. We are evaluating which BLE SoC will be used for our next generation devices and such a delay does not make the best impressions.

Cheers 

Oliver

[the_reza]

Hieu,

Sorry to hear about the health/family issues.  I wish you and your family a speedy recovery.

I'll summarize to try to help.  If you install the periperhal uart example and click on the 'erase and flash to board' button, you will get this error.  I've traced it down to the problem to some kernel call around a semaphore allocation as it's trying to see what else has been written in the NV ram before it writes the BTLE connection details there.  Look at my post in oct 12th with some screenshots to see the traces (i'm not sure how to link to it).

If you run the NV example first, then the code follows a different path as there is stuff in the NV memory and never hit that semaphore code, so it doesn't crash.  

Hope that helps.

Reza

[Hieu]

Hi the_reza and OliverDOM ,

My apology that this ticket was not followed up for a while.

Could you please check if using NCS 2.0.2 can be a workaround for now? It helped droidecaehdron in this thread:  peripheral uart sample: connecting causes permanent halting on background threads .

That is not to say that the issue in NCS 2.1.x won't be investigated. It will. But I want to arrange a workaround for you to continue your work as soon as possible.

Best regards,

Hieu

[the_reza]

Downloading 2.0.2 now.  Hopefully it's not hard to migrate the application over.  Will test tomorrow.

[OliverDOM]

Hi the_reza and Hieu ,
just tested with 2.0.2 and I can't reproduce the behavior.

Best regards

Oliver

[the_reza]

So it's a bug in 2.1 that's not there in 2.0?  Great - will migrate my code over to 2.0

I've not had a chance to test yet 

[the_reza]

also verified that the bug is gone with 2.0.2.