Course Bluetooth Low Energy Lesson 4 exercise 3

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Thu, 11 May 2023 14:11:45 GMT

I don't know what most customers are using. It is not something they have to say, but most questions where I notice the environment it is windows and linux.

If you are using NCS, VS Code is what we recommend. Eclipse in general is not supported by us. This doesn't mean it doesn't work, but we don't have tools for it. Segger is popular in the nRF5 SDK.

What do you mean by probe? Do you mean programmer? For us, that would be Segger.

BR,
Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Thu, 11 May 2023 12:06:03 GMT

Hi Edvin,

Yes I will do that. By the way, what would you say with your experience is most popular development environment for your products. Windows, Linux or MacOS. VSCode, Eclipse, SeggerIDE. And what probe is most use.

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Thu, 11 May 2023 11:30:51 GMT

Oh, and by the way. Let me know if you see a similar option in one of the other exercises.

BR,
Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Thu, 11 May 2023 07:12:43 GMT

Hello Anders,

To be honest, I wasn't aware of exactly what that checkbox did before yesterday me neither. I just noticed the difference in the project that you sent me and the project I downloaded from github.

I think this qualifies as a bug in the course. I have reported it back to the team who worked on it. All the applications in the course should be able to run without optimization.

[quote user="AndersB"]I suppose that you need some kind of probe if you are in for some serious development. What is your comment on that?[/quote]

I am not sure what you mean, but what I found in the end was the log messages telling me where the overflow was coming from. Knowing what I know now, i could've probably spotted this from the very first log that you posted. Still learning 🙂 I guess I have seen a lot of issues with pointers to callback functions being wrong, which was why I was asking for that a lot.

Anyway, thank you for helping me reproduce the issue that you were experiencing, so that we can use this to prevent other users running into the same issue.

Best regards,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Wed, 10 May 2023 13:49:52 GMT

Hi Edvin,

I check that box as a standard procedure. And today I hovered over the ? mark and saw those warnings for the first time.

I suppose that you need some kind of probe if you are in for some serious development. What is your comment on that?

I think you have a fairly good idea of what tools professionals use when developing hardware around Nordic components.

Thank you very much for helping me with this issue.

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Wed, 10 May 2023 12:26:12 GMT

Ok, good news. I am able to replicate an error when sending data from the phone to the DK using your project.

I see the same faulting instruction address (0x0000be44), but the lr/r14 is not the same.

I see that you added CONFIG_DEBUG_OPTIMIZATIONS=y in your prj.conf. I believe you added this manually, but it will also be added if you check the box saying "Enable debug options" when you create your build configuration.

The issue was that when this configurations is set to y, then a lot of optimizations are turned off. This causes the threads to require a bit more resources, and in this case, it is the RX thread in the BT stack that caused the issue. So if you want to have CONFIG_DEBUG_OPTIMIZATIONS=y, you need to increase the BT RX stack. By default it is 1024. I have not experimented with a lot of different sizes, but 2048 seems to work.

CONFIG_BT_RX_STACK_SIZE=2048

Try adding this to your prj.conf, and let me know if it doesn't solve the issue.

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Wed, 10 May 2023 06:55:07 GMT

Hi Edvin,

Here comes the files:

devzone.nordicsemi.com/.../nus.c

devzone.nordicsemi.com/.../nus.h

devzone.nordicsemi.com/.../blefund_5F00_less4_5F00_exer3_5F00_solution.zip

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Tue, 09 May 2023 19:06:43 GMT

Ok, good. I assume you didn't find anything on the address 0x220350d1 either (because it is way too high. It is not part of the flash).

Just drag and drop the zip file into where you are typing your answers. For good measure, can you please copy and upload your nus.c and nus.h files as well? I would like to see if any changes has sneaked in (and it saves us one day of back and forth if I were to ask for it tomorrow. You can find it in:

v2.3.0\nrf\subsys\bluetooth\services\nus.c
v2.3.0\nrf\include\bluetooth\services\nus.h

Best regards,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Tue, 09 May 2023 13:02:18 GMT

Hi Edvin,

As from what you can see from the log below the address to rc15 is 0x0000be44

SEGGER J-Link V7.80c - Real time terminal output
J-Link OB-nRF5340-NordicSemi compiled Nov 7 2022 16:22:01 V1.0, SN=1050395042
Process: JLink.exe
*** Booting Zephyr OS build v3.2.99-ncs2 ***
[00:00:00.001,007] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision:
d8 0c 2d 2f 36 ae e2 5c 80 26 80 4c 3f 4d 16 53 |..-/6..\ .&.L?M.S
50 96 c7 73 |P..s
[00:00:00.009,887] <inf> Lesson4_Exercise3: Bluetooth initialized
[00:01:18.736,846] <inf> Lesson4_Exercise3: Connected 60:49:5A:1A:31:70 (random)
[00:01:43.059,814] <inf> Lesson4_Exercise3: Disconnected: 60:49:5A:1A:31:70 (random) (reason 19)
[00:02:05.291,076] <inf> Lesson4_Exercise3: Connected 60:49:5A:1A:31:70 (random)
[00:02:30.002,838] <err> os: ***** MPU FAULT *****
[00:02:30.002,868] <err> os: Stacking error (context area might be not valid)
[00:02:30.002,868] <err> os: Data Access Violation
[00:02:30.002,899] <err> os: MMFAR Address: 0x20005070
[00:02:30.002,929] <err> os: r0/a1: 0x17e85fd0 r1/a2: 0x3541cc00 r2/a3: 0x7f5fe17e
[00:02:30.002,929] <err> os: r3/a4: 0x290050a8 r12/ip: 0xa6fffceb r14/lr: 0x220350d1
[00:02:30.002,960] <err> os: xpsr: 0x21000000
[00:02:30.002,960] <err> os: Faulting instruction address (r15/pc): 0x0000be44
[00:02:30.003,021] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:02:30.003,051] <err> os: Current thread: 0x20001eb8 (BT RX)
[00:02:30.279,449] <err> fatal_error: Resetting system

I have a zipfile waiting for you, but I could find a way to upload it.

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Tue, 09 May 2023 06:11:24 GMT

[quote user="AndersB"]arm-zephyr-eabi-addr2line -e build\zephyr\zephyr.elf 0x0000be44 gives ??[/quote]

You need to replace the address (0x000be44) with the address that you see on r15 in your log. The address 0x0000be44 was from Johanan's log. And as I mentioned, you can't use the value from your initial log. You need to compile the sample (or solution) from the academy course, so that you run into the original issue where it crashed when you were sending data from the phone to the DK.

I could send you the SDK that I am working on, and the source file, but that would be the exact same as you found on github (Blefund_Less4_Exer3_Solution), and the unmodified SDK that I downloaded from nRF Connect for Desktop -> Toolchain Manager. Those are the ones I have been testing on.

Besides, the SDK zip file isn't worth much without downloading it from Toolchain Manager, because this will also set up the toolchain for that specific SDK version (which you will need to compile the application).

Another suggestion: You replicate the issue that you saw originally, copy the log and upload it here, and zip your application folder (including the build folder) and upload it here. I feel I have said it a hundred times, but I can't stress it enough. When you have replicated the issue, do not rebuild the application before zipping your application folder. After you have reproduced the issue, copied the log, zipped the application folder and uploaded it here, you can build again if you like. This is to make sure that the log corresponds to the zipped application folder including the correct build folder.

Best regards,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Mon, 08 May 2023 14:45:16 GMT

Hi Edvin,

-> it suggests that there are some changes in your nus.c or nus.h file, <-

I have not modified any of these files.

The command:

arm-zephyr-eabi-addr2line -e build\zephyr\zephyr.elf 0x0000be44 gives ??

But looking up the file zephyr.elf gives you following:

0000BE40: 22 F0 10 02 02 60 00 29 00 D0 62 B6 10 BD 20 BF

Maybe another eay to track this down is you sending two zipfiles:

One that includes all sourcefile in the project (Blefund_Less4_Exer3_Solution) and

one that includes the SDK you are working with (C:\ncs\)

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Mon, 08 May 2023 13:14:13 GMT

Hello, both of you 🙂

[quote user="AndersB"]2. Since no crashes ocure, this point could not be fullfiled.[/quote]

I meant that you needed to do that in the application that you compiled. However, it is weird that it never exits settings_init. Did you erase the board completely before re-programming it? If not, please do. I have described how to do it in a previous reply.

Let me explain in more details what I am looking for when asking you to test different things:

When I ask you to test the peripheral_uart sample, it is to check whether the default sample works as intended or not. If it does not, it suggests that there are some changes in your nus.c or nus.h file, which is outside this course. But remember that changing this file while working one one application will affect other applications using the same file.

I also asked you a couple of times to erase the flash on the DK. The reason for this is to make sure that there are not some old/corrupt flash data stored in the end of the flash (which is not erased by default when you program a new application to the DK). The program going into a never ending loop in settings_init may suggest that this is the case.

And finally, the reason I want you to check the specific address from your logs is that these are the addresses of the functions that caused the application to crash. So both Anders and Johanan, please check r15 and r14 from your logs. Johanan, you have two sets of registers. Please check both.

To look up the functions, use the command:

arm-zephyr-eabi-addr2line -e build\zephyr\zephyr.elf <address>
e.g.:

arm-zephyr-eabi-addr2line -e build\zephyr\zephyr.elf 0x0000be44

And see what it outputs.

Again, make sure to use the log corresponding to your latest build. re-building the application will change the mapping of the functions.

Best regards,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Sat, 06 May 2023 15:23:23 GMT

Hi Edvin,

I did what you suggested me to do.

1. No, It does not behave the same. Program seemes to got into never ending loop inside settings_init.c.

2. Since no crashes ocure, this point could not be fullfiled.

But, if I download "nRF52 DK Peripheral UART demo.zip" from url:
www.nordicsemi.com/.../Download

and flash that to the board, everything is working.

Something must be wrong in the setup!?

Regards
Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Johan.h — Sat, 06 May 2023 10:26:49 GMT

Hi,

I have the same issue. When phone send even a single char, the program crashes with a stack overflow, but I could not find the RX thread creation point( also using NRF52832-DK )

Johanan

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Fri, 05 May 2023 09:37:34 GMT

I do indeed believe you, but since I am not able to replicate this issue, it is difficult to say exactly what's going on.

Here is what we will do. I want you to do both of these tests for me, and tell me what it behaves like.

1: In the SDK, there is a sample located in:

v2.3.0\nrf\samples\bluetooth\peripheral_uart

Compile this sample for the board that you are using: nrf52dk_nrf52832, flash it and test it. Does it behave the same?

2: Without debugging (remove all breakponits and just program it as you normally would using VS Code), monitor the RTT log, and trigger the issue:

[quote user=""]I seems that the program makes a reset upon receiving data from phone.[/quote]

Then check what the RTT log is saying. Copy and upload that updated crash log here. In addition, without building the application after the bug is triggered, zip and upload your build folder as well.

Best regards,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Fri, 05 May 2023 06:54:05 GMT

Hi Edvin,

I just saw this conversation:

Bluetooth LE course - Lesson 4 / Exercise 3 - Can't write data from phone Case ID: 306292

So I'm not alone with this problem.

Is there anything we can learn from that case?

Regards
Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Thu, 04 May 2023 13:39:31 GMT

Hi Edvin,

Does your (main) issue only occur after you stop at breakpoints?

I'm not sure I understand what you are getting for.

If the main issue occurs only after you receive messages from the phone, can you please try to either set a breakpoint or add something to the log to determine whether these applications are reached:

bt_receive_cb() in main.c

on_receive() in nus.c

Are any, or both of them reached? Add logs/breakpoints at the start and end of these functions to test. Remember if you are using breakpoints, you need to remove the breakpoint and restart the application to check whether the next one is reached.

Both are reached but when the breakpoint is reached in ether of these methods the debugger has crashed.

And trying to step forward when the debugger has crashed seems to rather pointless.

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Thu, 04 May 2023 11:58:47 GMT

I don't know. I have the same:

But that should not be what's causing your issues.

Please note that after you have reached a breakpoint, you need to restart the application. The reason for this is that the instance you break, the BLE stack has lost too many time critical operations, so the application will fail. So you can use breakpoints to investigate certain events or execution, but you can't resume the application after that. You need to restart.

Does your (main) issue only occur after you stop at breakpoints?

If the main issue occurs only after you receive messages from the phone, can you please try to either set a breakpoint or add something to the log to determine whether these applications are reached:

bt_receive_cb() in main.c

on_receive() in nus.c

BR,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Wed, 03 May 2023 15:44:48 GMT

Hi Edvin,

I think it is established that program reached the place in the program where text from phone was received. Below is a dump from the Debug Console:

-------------------------------------------------------------------------------------------------------------------------------

JLinkGDBServerCL: SEGGER J-Link GDB Server V7.80c Command Line Version
JLinkGDBServerCL:
JLinkGDBServerCL: JLinkARM.dll V7.80c (DLL compiled Sep 27 2022 16:06:20)
JLinkGDBServerCL:
JLinkGDBServerCL: -----GDB Server start settings-----
JLinkGDBServerCL: GDBInit file: none
JLinkGDBServerCL: GDB Server Listening port: 55791
JLinkGDBServerCL: SWO raw output listening port: 2332
JLinkGDBServerCL: Terminal I/O port: 2333
JLinkGDBServerCL: Accept remote connection: localhost only
JLinkGDBServerCL: Generate logfile: off
JLinkGDBServerCL: Verify download: off
JLinkGDBServerCL: Init regs on start: off
JLinkGDBServerCL: Silent mode: on
JLinkGDBServerCL: Single run mode: on
JLinkGDBServerCL: Target connection timeout: 0 ms
JLinkGDBServerCL: ------J-Link related settings------
JLinkGDBServerCL: J-Link Host interface: USB
JLinkGDBServerCL: J-Link script: none
JLinkGDBServerCL: J-Link settings file: none
JLinkGDBServerCL: ------Target related settings------
JLinkGDBServerCL: Target device: nRF52832_xxAA
JLinkGDBServerCL: Target device parameters: none
JLinkGDBServerCL: Target interface: SWD
JLinkGDBServerCL: Target interface speed: 12000kHz
JLinkGDBServerCL: Target endian: little
JLinkGDBServerCL:
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
atomic_get (target=0x20003160 <force_isr_mask>) at C:/ncs/v2.3.0/zephyr/include/zephyr/sys/atomic_builtin.h:161
161 return __atomic_load_n(target, __ATOMIC_SEQ_CST);
[New Remote target]
[New Thread 536882016]
[New Thread 536881832]
[New Thread 536877104]
[New Thread 536878376]
[New Thread 536881616]
[New Thread 536882200]
[New Thread 536876872]
[New Thread 536878592]
[New Thread 536878776]
[New Thread 536881432]
[Switching to Thread 536882016]

Thread 3 hit Breakpoint 1, main () at ../src/main.c:564
564 {
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
[New Thread 536878592]
[New Thread 536878776]
[New Thread 536881432]
[Switching to Thread 536878776]

Thread 14 hit Breakpoint 2, bt_receive_cb (conn=0x20001f90 <acl_conns>, data=0x20008849 <net_buf_data_hci_rx_pool+81> "Hello from phone ~�\b&\002S\235n\002\002\f)/Z��\022g؄{�i�\210(�A�{��ߡ \025��(P0", len=17) at ../src/main.c:458
458 char addr[BT_ADDR_LE_STR_LEN] = {0}; // BT_ADDR_LE_STR_LEN
[New Remote target]
[Switching to Remote target]
/__w/_temp/workspace/build/.build/HOST-x86_64-w64-mingw32/arm-zephyr-eabi/src/gdb/gdb/infrun.c:8553: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/__w/_temp/workspace/build/.build/HOST-x86_64-w64-mingw32/arm-zephyr-eabi/src/gdb/gdb/infrun.c:8553: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
ERROR: GDB exited unexpectedly with exit code 3 (0x3). Debugging will now abort.
The program 'c:/Nordic/MyApps/bt-fund/lesson4/blefund_less4_exer3_solution/build/zephyr/zephyr.elf' has exited with code -1 (0xffffffff).

-------------------------------------------------------------------------------------------------------------------------------

But the information about "A problem internal to GDB has been detected" worries a bit. That is outside my scope. So what's wrong.

Another thing, is the red colored text normal: See below?

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Tue, 02 May 2023 21:32:55 GMT

Sorry for this vague reply, but the "Problems" tab is a bit buggy. I have a lot of things listed there all the time, but it doesn't really matter. What really matters is what it says when you build, and what you see in the build log.

Are you able to build after you set it up again? What happens if you flash it? Did you try the "erase and flash" button I pointed to in my previous reply?

If you still see the same error in your log, did you try the arm-zephyr-eabi-addr2line command that I showed you in the previous reply?

BR,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Tue, 02 May 2023 11:55:03 GMT

Hi Edvin,

I would very much try to solve the problem, so I formated a disk and installed a new windows 10. Then I made all preparations to set up nRF developing environment.

I attach two pictures, one that show the setup and one that shows a number of problems.

What is the warnings in prj.conf?

What is the invalid type definition: Cannot set properties of null (setting 'name') [ln 1, col1]

I have of course not touched any file coming from Nordic.

Worth mentioning I can still send info from PC to the phone.

Regards

Anders

Picture 1:

Picture 2:

I hope you can enlarge these pictures.

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Fri, 28 Apr 2023 09:31:31 GMT

[quote user="AndersB"]But I am curious about if there is some difference between erasing with west before flashing and just flash from VScode.[/quote]

Just flash from VScode will only erase the flash pages that holds the application, but it will leave the rest of the flash untouched. Many of our BLE applications support bonding, so if you have ran an application that stored bonding data on the DK, this will be stored in a different location than the flash that holds the application. (still in flash, but a different address). So when you start a new application, and it sees old bonding information it may think that this is still relevant. So the difference by pressing the button (in VS Code that I circeled red) that erases the flash before flashing the application is that it will delete all flash, and then re-program the kit.

[quote user="AndersB"]When I tried that I bumped into a lot of problems.[/quote]

I can't think of why that should be. What do you see?

From your log, it is not very easy to say exactly what went wrong.

The faulting instruction is located in 0x0000be44, so you can look that up in your build folder using the command:

arm-zephyr-eabi-addr2line -e build\zephyr\zephyr.elf -e 0xbe44

(run that from a terminal that you open using nRF Connect for Desktop -> Toolchain Manager -> click the down button next to the NCS version you are using and select "Open command prompt")

You can also check what is in the Link Register (LR/r14), 0x200350d1 using the command:

arm-zephyr-eabi-addr2line -e build\zephyr\zephyr.elf -e 0x200350d1

Please note that when you recompile, these addresses may change, so remember to use the addresses from your most recent log (and make sure you don't rebuild in the meantime).

However, if you say that it happens when you write a message from the phone to the nRF chip, you can try to start looking into the on_receive() callback function in nus.c. Try setting a breakpoint and see if it is reached. Is it? If it is, is nus_cb.received assigned a value that is not NULL? What happens when it tries to call

nus_cb.received(conn, buf, len);

I wish I could give a more "to the point" answer, but I am not able to reproduce what you are seeing. Perhaps you changed something in nus.c or nus.h at some point earlier, which is now causing the issues you are seeing?

Best regards,

Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Fri, 28 Apr 2023 08:10:53 GMT

Hi,

I have not changed anything in the project.

There is no bonding information in my phone.

I have not used the west command for erasing.

When I tried that I bumped into a lot of problems. So I am considering a reinstall of the Nordic development development.

But I am curious about if there is some difference between erasing with west before flashing and just flash from VScode.

But I will be back when I am up and running with the development.

Regards

Anders

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

Edvin — Thu, 27 Apr 2023 14:00:36 GMT

Can you please confirm that:

1: You didn't change anything in the project?

2: You deleted Bluetooth bonding information (if present) on the phone?

3: You erased the board before programming it the way I described in the previous reply?

This happens when you try to send data, right? Is it a long string of data, or a fairly short one?

BR,
Edvin

RE: Course Bluetooth Low Energy Lesson 4 exercise 3

AndersB — Wed, 26 Apr 2023 13:45:49 GMT

OK, back on nRF52DK (build nRF52 DK NRF52832). So I installed the JLink RTT Viewer and I selected NRF52 as the best choice I could see.

And here is the answer where sending Hello from my Pixel:

00> *** Booting Zephyr OS build v3.2.99-ncs2 ***

00> [00:00:00.000,976] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision:

00> d8 0c 2d 2f 36 ae e2 5c 80 26 80 4c 3f 4d 16 53 |..-/6..\ .&.L?M.S

00> 50 96 c7 73 |P..s

00> [00:00:00.009,765] <inf> Lesson4_Exercise3: Bluetooth initialized

00> [00:03:22.308,074] <inf> Lesson4_Exercise3: Connected 74:74:29:09:B4:B1 (random)

00> [00:03:55.406,341] <err> os: ***** MPU FAULT *****

00> [00:03:55.406,372] <err> os: Stacking error (context area might be not valid)

00> [00:03:55.406,372] <err> os: Data Access Violation

00> [00:03:55.406,402] <err> os: MMFAR Address: 0x20005070

00> [00:03:55.406,433] <err> os: r0/a1: 0x1ee85fd0 r1/a2: 0x3541cc00 r2/a3: 0x3f5fa17e

00> [00:03:55.406,433] <err> os: r3/a4: 0x290052a9 r12/ip: 0xa6fffcef r14/lr: 0x200350d1

00> [00:03:55.406,463] <err> os: xpsr: 0x21000000

00> [00:03:55.406,463] <err> os: Faulting instruction address (r15/pc): 0x0000be44

00> [00:03:55.406,494] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0

00> [00:03:55.406,555] <err> os: Current thread: 0x20001eb8 (BT RX)

00> [00:03:55.682,922] <err> fatal_error: Resetting system

00> *** Booting Zephyr OS build v3.2.99-ncs2 ***

00> [00:00:00.001,190] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision:

00> d8 0c 2d 2f 36 ae e2 5c 80 26 80 4c 3f 4d 16 53 |..-/6..\ .&.L?M.S

00> 50 96 c7 73 |P..s

00> [00:00:00.009,918] <inf> Lesson4_Exercise3: Bluetooth initialized

Hope this will point out the error.

Regards

Anders