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

[ovrebekk]

Hi Renato

The peripheral_uart sample doesn't use MPSL, so I assume you made some changes to it? 

Also, what is the link between the call to mpsl_timeslot_request(..) and flash memory access?

Would you be able to share your modified sample with me so I can have a look at it? 

If you don't want to share your code in a public ticket just let me know, and I can make it private. 

Best regards
Torbjørn

[renato_lynx]

Hello Torbjørn!

Thank you for the help.

But I didn't modify the example. All I did was:
On the nRF Connect for VS Code welcome page, I selected "Create a new application"
I selected Freestanding, SDK and Toolchain version 2.4.0, and the Application Template "nrf/samples/bluetooth/peripheral_uart"
Then, in the applications, I clicked on "Add Build Configuration", selected the board "nrf52833dk_nrf52833", Configuration "Use build system default" and then enabled the debug options
After that, I clicked in the Action "Debug".

The program downloads and runs in the board, but it resets after reaching the line

ret = mpsl_timeslot_request(_context.session_id, req);

The call stack is this:

Thank you again

Renato

[ovrebekk]

Hi Renato

That sounds strange, the example should run normally. 

Did you try to do an erase all before flashing the code? 
You can do this from the command line using nrfjprog:

nrfjprog -e

I assume you don't have more than one board to test with? 

Could you let me know what the version and date code on your DK is, printed on the white label? 

Could you try the NVS sample on your board and see if this works? 

Best regards
Torbjørn

[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