Running a uart bluetooth example on nRF52833 DK

[renato_lynx]

Hello!

I am trying to run the bluetooth peripheral_uart example on the nRF52833 Development Kit, but when I run the debugger, the program keeps reseting when calling 

bt_enable(NULL). I tracked the problem to the following call, when trying to write to the flash memory:

ret = mpsl_timeslot_request(_context.session_id, req);

I found a similar problem here:

 RE: Halt on nvs_init() 

But I was unable to understand the solution. 

Can someone help me with this?

 

I am using nRF Connect for VS Code

nRF Connect SDK and Toolchain version 2.4.0

Using the example nrf/samples/bluetooth/peripheral_uart

 

Renato

[renato_lynx]

Hello Torbjørn!

Tried the erase all, but it did not solve the problem.

Then, I tried the NSV sample, and it works fine!

I also tried the peripheral_lbs sample, and it also works correctly.

Just the peripheral_uart doesn't work...

I only have this board. I am not sure which number is the version and date code, so I am sending a picure

Best regards

Renato

[ovrebekk]

Hi Renato

Both the NVS sample and peripheral_lbs works? 
This issue keeps getting weirder....

What if you comment out uart_init() at the start of main.c, does this make a difference? 
I can't really spot any other major differences between the peripheral_uart and peripheral_lbs samples until after bt_enable(..) is called, but when I run the peripheral_lbs sample myself I notice that the nvs_add_gc_done_ate(..) function does not seem to get called. 

Exactly what triggers the calling of this function I am not sure, but since it is a part of your call stack it appears to be related to this issue. 

Could you try to run the peripheral_uart sample with logging enabled in the NVS module and see if you get some more information? 

I tested the code with the following log configuration: 

# Config logger
CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_PRINTK=n
CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_LOG_MODE_DEFERRED=n

Best regards
Torbjørn

[renato_lynx]

Hello, Torbjørn

Commenting uart_init() did not change the problem.

The debug message is

*** Booting Zephyr OS build v3.3.99-ncs1 ***
Starting Nordic UART service example
[00:00:00.004,943] <dbg> fs_nvs: nvs_recover_last_ate: Recovering last ate from sector 0
[00:00:00.017,120] <dbg> fs_nvs: nvs_add_gc_done_ate: Adding gc done ate at ff0
[00:00:00.017,181] <err> os: ***** HARD FAULT *****
[00:00:00.017,211] <err> os: Fault escalation (see below)
[00:00:00.017,211] <err> os: ***** MPU FAULT *****
[00:00:00.017,242] <err> os: Data Access Violation
[00:00:00.017,242] <err> os: MMFAR Address: 0x20006f22
[00:00:00.017,272] <err> os: r0/a1: 0x00000000 r1/a2: 0x4001e700 r2/a3: 0x00000002
[00:00:00.017,303] <err> os: r3/a4: 0x00000000 r12/ip: 0x00000000 r14/lr: 0x000092d1
[00:00:00.017,303] <err> os: xpsr: 0x61000000
[00:00:00.017,333] <err> os: Faulting instruction address (r15/pc): 0x000092f6
[00:00:00.017,364] <err> os: >>> ZEPHYR FATAL ERROR 19: Unknown error on CPU 0
[00:00:00.017,395] <err> os: Current thread: 0x20002e48 (main)
[00:00:00.106,048] <err> os: Halting system

But the good news is: I managed to make it work! Because the problem is a Data Access Violation, I was thinking that the call stack was very deep and maybe the stack size was not enough... so I increased the main stack size from 1024 (the default value) to 2048 and it worked!

Then, returning the stack size to 1024, it still works because the program doesn't call nvs_add_gc_done_ate(..) anymore. However, if I erase the flash with the command "nrfjprog -e", then it fails again because it tries to run nvs_add_gc_done_ate().

So basically, when the program executes nvs_add_gc_done_ate() with a main stack size of 1024, a Data Access Violation occurs. Increasing the stack size to 2048, the program works.

Thank you for the help, Torbjørn!

Best Regards

Renato

[ovrebekk]

Hi Renato

That is excellent news, thanks for sharing your findings 

A good old stack overflow then. I should have been suspicious when you shared the call stack earlier, it was pretty deep after all.

Also, this issue is probably present in any board using internal flash and the settings library. I will request if this can be increased in the sample.  

Best regards
Torbjørn