Running a uart bluetooth example on nRF52833 DK

RE: Running a uart bluetooth example on nRF52833 DK

ovrebekk — Tue, 04 Jul 2023 07:54:13 GMT

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

RE: Running a uart bluetooth example on nRF52833 DK

renato_lynx — Mon, 03 Jul 2023 17:21:22 GMT

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

RE: Running a uart bluetooth example on nRF52833 DK

ovrebekk — Mon, 03 Jul 2023 13:08:33 GMT

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

RE: Running a uart bluetooth example on nRF52833 DK

renato_lynx — Fri, 30 Jun 2023 16:25:09 GMT

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

RE: Running a uart bluetooth example on nRF52833 DK

ovrebekk — Fri, 30 Jun 2023 11:15:41 GMT

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

RE: Running a uart bluetooth example on nRF52833 DK

renato_lynx — Thu, 29 Jun 2023 15:07:39 GMT

Hello Torbjørn

Even when I just flash the board, it still doesn't work. The LED1 does not blink and the bluetooth radio doesn't show up, so the program never finished the initialization.

I tried to enable CONFIG_DEBUG=y but still no success.

But it works when I skip (when I comment) this part of the code:

settings_backend_init();

(This line is part of the call stack I sent before)

In this case, the program finishes the initialization, starts the bluetooth radio, and the serial example works fine (transmitting data through the radio/uart).

I don't know if there is a problem in the example or on my board, or if I am doing something wrong.

I think I will try another example and check if the same problem shows up.

Best Regards

Renato

RE: Running a uart bluetooth example on nRF52833 DK

ovrebekk — Thu, 29 Jun 2023 09:42:01 GMT

Hi Renato

My bad, I forgot that MPSL will be used by the internal flash libraries.

I assume the code runs fine if you just flash the board and reset it without entering debug mode?

What if you enable CONFIG_DEBUG=y in the prj.conf file, does this make any difference?

Will the code crash if you simply reset the board and press Continue (F5), or do you need to put breakpoints in the code to make it crash?

Debugging when running the Bluetooth stack and the MPSL module can be problematic once you put breakpoints in the code. The timer used by the stack/MPSL scheduler will keep running in the background, and if you try to continue execution after a breakpoint it will often crash, since the internal timing breaks while the code is halted.

Best regards
Torbjørn

RE: Running a uart bluetooth example on nRF52833 DK

renato_lynx — Wed, 28 Jun 2023 16:02:26 GMT

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

RE: Running a uart bluetooth example on nRF52833 DK

ovrebekk — Wed, 28 Jun 2023 11:55:55 GMT

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