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

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

[renato_lynx]

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

[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