IPC problem with a custom board nrf5340

[brendow]

HI guys, I'm trying to figure out whether the problem I'm having is a hardware or software issue.

 

So, my problem is: I have created a custom board using the nrf5340 and I'm debugging the hardware/software now. It's a basic PCB with USB and FEM.

 

In the part of USB, everything worked fine, and I can access the hardware through the USB using the `CDC USB`.

 

But when I tried to run this sample [openthread/cli](`https://github.com/nrfconnect/sdk-nrf/tree/main/samples/openthread/cli`) and used the command `ot scan` it got stuck and I can't send more to the terminal commands using `ot`. 

 

Then I decided to add the following Kconfigs in my project to see what happened:

 

```

CONFIG_OPENTHREAD_LOG_LEVEL_DEBG=y

CONFIG_OPENTHREAD_DEBUG=y

CONFIG_OPENTHREAD_L2_DEBUG=y

```

 

and the output in the terminal was:

```sh

[00:00:00.348,175] <inf> ieee802154_nrf5: nRF5 802154 radio initialized
[00:00:00.354,644] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:00.354,644] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.354,644] <inf> fs_nvs: data wra: 0, 70
[00:00:00.356,079] <dbg> [D] SubMac--------: RadioState: Disabled -> Sleep
[00:00:00.359,649] <dbg> [D] SubMac--------: RadioExtAddress: d223be944a906d83
[00:00:00.360,015] <dbg> [D] SubMac--------: RadioShortAddress: 0xfffe
[00:00:00.360,626] <dbg> [D] SrcMatchCtrl--: Cleared all entries
[00:00:05.381,530] <inf> cli_sample:

OpenThread Command Line Interface is now running.
Use the 'ot' keyword to invoke OpenThread commands e.g. 'ot thread start.'
For the full commands list refer to the OpenThread CLI documentation at:
github.com/.../README.md

uart:~$ ot scan
| PAN | MAC Address | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
[00:00:09.638,732] <dbg> [D] Mac-----------: Request to start operation "ActiveScan"
[00:00:09.638,885] <dbg> [D] Mac-----------: Starting operation "ActiveScan"
[00:00:09.639,434] <dbg> [D] SubMac--------: RadioPanId: 0xffff
[00:00:09.639,556] <inf> [I] Mac-----------: Sending Beacon Request
[00:00:09.639,678] <dbg> [D] SubMac--------: RadioState: Sleep -> CsmaBackoff
[00:00:09.639,801] <dbg> [D] SubMac--------: RadioState: CsmaBackoff -> Transmit
uart:~$

```

 

Ok, is something weird happening here...It gets stuck when I try to transmit the signal, and if we see the datasheet of the (nrf5340 v1.5)[https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/soc_overview/doc/instantiation.html] says:

```

The application core peripherals are accessible from the network core, but the network core peripherals are not accessible from the application core.

```

 

I guess the problem is related to the IPC. Somehow, the application core tries to send the transmission to the network core, and neither the network core nor the application core receives the request or the response.

 

So, I tried to use the [ipc service sample](https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/nrf/samples/ipc/ipc_service/README.html) to see if the problem is it. The following are the results of `rpmsg_cpuapp_sending` and `icmsg_cpuapp_sending` using just one core:

 

APP CORE (RPMSG)

Command: 

west build -p -b unny/nrf5340/cpuapp -T sample.ipc.ipc_service.unny_rpmsg_cpuapp_sending .

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpuapp demo started
Δpkt: 43032 (100 B/pkt) | throughput: 34425600 bit/s
Δpkt: 43004 (100 B/pkt) | throughput: 34403200 bit/s
Δpkt: 43056 (100 B/pkt) | throughput: 34444800 bit/s
Δpkt: 43009 (100 B/pkt) | throughput: 34407200 bit/s
Δpkt: 43004 (100 B/pkt) | throughput: 34403200 bit/s
Δpkt: 42994 (100 B/pkt) | throughput: 34395200 bit/s
Δpkt: 42990 (100 B/pkt) | throughput: 34392000 bit/s
Δpkt: 43005 (100 B/pkt) | throughput: 34404000 bit/s
Δpkt: 43002 (100 B/pkt) | throughput: 34401600 bit/s
Δpkt: 42998 (100 B/pkt) | throughput: 34398400 bit/s

```

 

NET CORE (RPMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpunet demo started
[00:00:00.516,967] <inf> sync_rtc: Updated timestamp to synchronized RTC by 8300 ticks (253295us)
Δpkt: 1 (100 B/pkt) | throughput: 800 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s

```

 

APP CORE (ICMSG)

Command: 

west build -p -b unny/nrf5340/cpuapp -T sample.ipc.ipc_service.unny_icmsg_cpuapp_sending .

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpuapp demo started

```

NET CORE (ICMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpunet demo started
[00:00:06.300,170] <inf> sync_rtc: Updated timestamp to synchronized RTC by 103052 ticks (3144897us)

```

 

Building now just to cpunet sending the data. It is obtained:

APP CORE (ICMSG)

Command: 

west build -p -b unny/nrf5340/cpuapp -T sample.ipc.ipc_service.unny_icmsg_cpunet_sending .

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpuapp demo started

```

 

NET CORE (ICMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpunet demo started
[00:00:03.351,257] <inf> sync_rtc: Updated timestamp to synchronized RTC by 54737 ticks (1670440us)

```

 

APP CORE (RPMSG)

Command: 

west build -p -b unny/nrf5340/cpuapp -T sample.ipc.ipc_service.unny_rpmsg_cpunet_sending .

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpuapp demo started
Δpkt: 1 (100 B/pkt) | throughput: 800 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s

```

 

NET CORE (RPMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpunet demo started
[00:00:00.516,967] <inf> sync_rtc: Updated timestamp to synchronized RTC by 8300 ticks (253295us)
Δpkt: 33643 (100 B/pkt) | throughput: 26914400 bit/s
Δpkt: 33669 (100 B/pkt) | throughput: 26935200 bit/s
Δpkt: 33686 (100 B/pkt) | throughput: 26948800 bit/s
Δpkt: 33684 (100 B/pkt) | throughput: 26947200 bit/s
Δpkt: 33688 (100 B/pkt) | throughput: 26950400 bit/s
Δpkt: 33692 (100 B/pkt) | throughput: 26953600 bit/s

```

 

Ok, removing the fact that the ICMSG is showing no logs, the CPUs using the RPMSG are working. Now let’s set to default the build to both application and network cores periodically print out the receiving speed of data that was sent by the other core.

When I use the icmsg_default in my build the APP and NET logs:

 

APP CORE (ICMSG)

```sh

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpuapp demo started

```

 

NET CORE (ICMSG)

```sh

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpunet demo started
[00:00:00.516,387] <inf> sync_rtc: Updated timestamp to synchronized RTC by 8290 ticks (252990us)

```

and nothing more happens.

 

Building it now to rpmsg_default I receive:

APP CORE (RPMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpuapp demo started
Δpkt: 33 (100 B/pkt) | throughput: 26400 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s
Δpkt: 0 (100 B/pkt) | throughput: 0 bit/s

```

 

NET CORE (RPMSG)

```
*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
IPC-service unny/nrf5340/cpunet demo started
[00:00:00.516,845] <inf> sync_rtc: Updated timestamp to synchronized RTC by 8298 ticks (253234us)
Δpkt: 9255 (100 B/pkt) | throughput: 7404000 bit/s
Δpkt: 9738 (100 B/pkt) | throughput: 7790400 bit/s
Δpkt: 9929 (100 B/pkt) | throughput: 7943200 bit/s
Δpkt: 9928 (100 B/pkt) | throughput: 7942400 bit/s
Δpkt: 9931 (100 B/pkt) | throughput: 7944800 bit/s
Δpkt: 9928 (100 B/pkt) | throughput: 7942400 bit/s
Δpkt: 9932 (100 B/pkt) | throughput: 7945600 bit/s
Δpkt: 9928 (100 B/pkt) | throughput: 7942400 bit/s
Δpkt: 9928 (100 B/pkt) | throughput: 7942400 bit/s

```

seems close to [the sample log](https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/nrf/samples/ipc/ipc_service/README.html) removing the part that my APP Core is sending nothing.  

The only way to get the log similar to the one in the website is using the solution found https://devzone.nordicsemi.com/f/nordic-q-a/97387/sample-ipc_service-failed-in-ncs-v2-3-0 where it increase the interval that the IPC service send the interval to 20ms.

APP CORE (RPMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***

*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

IPC-service unny/nrf5340/cpuapp demo started

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

Δpkt: 49 (100 B/pkt) | throughput: 39200 bit/s

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

```

 

NET CORE (RPMSG)

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***

*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

IPC-service unny/nrf5340/cpunet demo started

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

[00:00:04.614,440] <inf> sync_rtc: Updated timestamp to synchronized RTC by 75434 ticks (2302062us)

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

Δpkt: 49 (100 B/pkt) | throughput: 39200 bit/s

Δpkt: 50 (100 B/pkt) | throughput: 40000 bit/s

```

 

This is weird… Why did the delay time increase work? It seems like a sync problem with RX TX or a problem with the processing.

Ok, just to be sure that my IPC is not working properly I decided to test the radio using the [radio test.](https://github.com/nrfconnect/sdk-nrf/tree/main/samples/peripheral/radio_test)

 

I changed the [subsys/shell/shell_ipc.c][ https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/shell/shell_ipc.c] changing all LOG_DBG to LOG_INF because I want to see the logs. After that I flashed the firmware in my MCU and used the command:

 

```sh

$> screen /dev/ttyACM0

```

 

After using the command, the LOG that shows to me in RTT is:

 

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***

*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

[00:00:02.047,790] <inf> remote_shell: Wait for DTR

[00:00:02.051,849] <inf> usb_cdc_acm: Device suspended

[00:00:02.169,494] <inf> usb_cdc_acm: Device resumed

[00:00:02.169,494] <inf> usb_cdc_acm: from suspend

[00:00:02.413,940] <inf> usb_cdc_acm: Device configured

[00:00:07.051,177] <inf> remote_shell: DTR set

[00:00:08.068,450] <inf> remote_shell: Baudrate detected: 9600

```

 

But nothing appears on screen I have just a blank terminal, but when I decided to type some characters in this blank terminal the LOG in the RTT changes:

 

```

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***

*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

[00:00:02.047,790] <inf> remote_shell: Wait for DTR

[00:00:02.051,849] <inf> usb_cdc_acm: Device suspended

[00:00:02.169,494] <inf> usb_cdc_acm: Device resumed

[00:00:02.169,494] <inf> usb_cdc_acm: from suspend

[00:00:02.413,940] <inf> usb_cdc_acm: Device configured

[00:00:07.051,177] <inf> remote_shell: DTR set

[00:00:08.068,450] <inf> remote_shell: Baudrate detected: 9600

[00:01:32.637,664] <inf> remote_shell: Sent 1 bytes

[00:01:32.756,530] <inf> remote_shell: Sent 1 bytes

[00:01:32.848,968] <inf> remote_shell: Sent 1 bytes

[00:01:32.996,948] <inf> remote_shell: Sent 1 bytes

[00:01:33.033,782] <inf> remote_shell: Sent 1 bytes

[00:01:33.126,281] <inf> remote_shell: Sent 1 bytes

[00:01:33.219,909] <inf> remote_shell: Sent 2 bytes

```

 

That is, the microcontroller receives input from my keyboard, but unlike the openthread cli that we have a working CLI here, nothing appears to me. It seems that there is a problem with the communication between CPUAPP and CPUNET that is not working and showing me the cli.

 

I won't put the .dts and kconfigs here in text because it will make the text bigger, but I will attach all the .dts, prj.conf and my PCB devicetree.

My questions are:

-> About the ipc example.

Why doesn’t the application core showing a similar log on the website when I build the default?

Why doesn't it show the log when using RPMSG?

 -> About the radio test example.

Why can't I access the ipc shell?

How can I access the ipc shell?

Why isn't my radio working?

How can I find out what's going on with my radio?

 

Any help in finding out what's going on would be appreciated.

 

Thanks.

unny_dts.zip6562.radio_test.zipipc_service.zip

[Edvin]

Hello,

A lot of information here. Are you able to reproduce the original issue you are having on the openthread sample on a DK? If so, is it possible to upload that application here, so that I can have a look?

Are you using nRF Connect SDK v2.9.0 for everything here?

Best regards,

Edvin

[brendow]

Hi Edvin,

Edvin said:

Are you able to reproduce the original issue you are having on the openthread sample on a DK?

I don't have a problem building these samples in my DK, only when using my custom board.

Edvin said:

Are you using nRF Connect SDK v2.9.0 for everything here?

Yes.

My question is: How can I see if IPC is working on my custom board? Because I'm unable to access the ipc shell from radio_test sample and the ipc_service had results different from your examples.

Could it be a problem with my devicetree, Kconfig or maybe HFXO?

Best regards,

Brendow

[Edvin]

Hello,

I know that there have been issues with the IPC samples before (although I don't know the current state of it). The IPC communication between the application core and network core on the nRF5340, on the other hand, usually works without any issues. There aren't any external components needed for this, so it is probably not related to the issue that you are seeing.

brendow said:

Could it be a problem with my devicetree, Kconfig or maybe HFXO?

That is more likely to be the "issue". Either that something is not configured correctly, or possibly that some components are out of specification. 

Does your custom board have an LFXTAL? If not, try adding this to your prj.conf:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

Best regards,

Edvin

[brendow]

Hi Edvin, I bring some updates.

I have two custom boards here. One of them, which I'm having trouble with, has an external LFXTAL , while the other one doesn’t. I decided to test both boards using only the internal oscillator.

The board with the external LFXTAL and the issue will be called B1, and the board without it will be called B2.

There seems to be something wrong with the nrf5340 on the B1. As I mentioned in the previous thread, when I was flashing the radio_shell, the terminal I was accessing via USB was blank. However, after I added a k_msleep(100) inside the while loop in the clock_init(), it started working.

I’m not sure why adding this 100ms delay in the loop makes a difference. The only explanation I can think of is that the while loop isn’t giving the CPU enough time to run other processes, but that shouldn’t be happening.

So, I tested the same code without the 100ms delay on B2, and it worked fine.

After this, I flashed the ot-cli sample on B2, and it also worked. So, the issue seems to be with B1.

While debugging both boards using CONFIG_NRF_802154_SER_LOG=y, I noticed that the CPU_APP on B1 gets stuck at net_generic_bool_response_await, specifically at this semaphore.

Meanwhile, on B1, CPU_NET’s last message is sending a spinel frame.

However, when I debugged B2, I saw that after CPU_NET sends a frame to CPU_APP, it calls the function nrf_802154_transmitted_raw because of an IRQ in swi_irq_handler(), which triggers nrf_802154_notification_swi() and eventually calls nrf_802154_transmitted_raw().

But when I debug B1, I see that the IRQ caused by nrf_swi never happens. Why is that? Could it be an issue with the nrf5340? Since I’m now using the RC oscillator, is there something on the board that could be causing problems?

I don't know why, but the IRQ that should be called after CPU_APP calls nrf_802154_transmit_csma_ca_raw never happens.

Best Regards,

 Brendow

[Edvin]

brendow said:

k_msleep(100) inside the while loop in the clock_init(), it started working

Was this before or after using the internal oscillator?

So it is only one device where you are seeing these issues? Is it in a particularly noisy environment? Have you tried it on a DK? Do you see the same issue there?

Also, with the board that is getting stuck. Can you please specify the chain of ot-cli commands that you call, and where it gets stuck (on what command)?

Best regards,

Edvin

[brendow]

Edvin said:

Was this before or after using the internal oscillator?

Using the external and the internal is the same result. The shell only appears when I've added the delay on my B1.

Edvin said:

So it is only one device where you are seeing these issues?

Yes, just on a specific board (B1).

Edvin said:

Is it in a particularly noisy environment?

I don't think so, the board is connected to my computer USB, and I'm trying to create a Thread network using two boards with the ot-cli sample.

Edvin said:

Have you tried it on a DK? Do you see the same issue there?

Yes, I tried and No, I don't. Everything works the same when testing on B2 or DK.  I don't think this might be a problem in your code, it's more about an issue in this specific custom board (B1) that I'm trying to figure out what's going on.

Edvin said:

Can you please specify the chain of ot-cli commands that you call, and where it gets stuck (on what command)?

I use the following commands:

ot scan

here is the image of my shell using the B1 and the image using the B2. I only used ot scan on both boards after connecting to the shell.

The B1 gets stuck because the IRQ on the CPU_NET never happens after the CPU_APP calls the nrf_802154_transmit_csma_ca_raw(). Then, the nrf_802154_transmitted_raw() is never called on the B1's CPU_NET.

Best regards,

Brendow

[Edvin]

Hello Brendow,

Ok, let's check some basics on your B1. 

For debugging purposes, can you please try to run a BLE sample? E.g.:

NCS\nrf\samples\bluetooth\peripheral_uart

Are you able to run it? Can you see any advertisements if you scan for nearby devices using your phone (nRF Connect for Android/iOS)?

Can you connect to it? Does it maintain a stable connection?

BR,

Edvin

[brendow]

Hi Edvin,

Edvin said:

Are you able to run it?

Yes, CPU_APP works, but in CPU_NET an MPSL assertion occurs.

[00:00:00.057,098] <inf> ipc_radio: Received hci message of 36 bytes. [00:00:00.057,434] <inf> ipc_radio: Sent message of 7 bytes. [00:00:00.057,739] <inf> ipc_radio: Received hci message of 36 bytes. [00:00:00.058,074] <inf> ipc_radio: Sent message of 7 bytes. [00:00:00.058,410] <inf> ipc_radio: Received hci message of 5 bytes. [00:00:00.058,837] <inf> ipc_radio: Sent message of 7 bytes. ASSERTION FAIL [0] @ WEST_TOPDIR/nrf/subsys/mpsl/init/mpsl_init.c:299 MPSL ASSERT: 112, 1557 [00:00:05.591,186] <err> os: ***** HARD FAULT ***** [00:00:05.591,186] <err> os: Fault escalation (see below) [00:00:05.591,217] <err> os: ARCH_EXCEPT with reason 4 [00:00:05.591,247] <err> os: r0/a1: 0x00000004 r1/a2: 0x0000012b r2/a3: 0x00000002 [00:00:05.591,247] <err> os: r3/a4: 0x00000004 r12/ip: 0x00000010 r14/lr: 0x010221d3 [00:00:05.591,278] <err> os: xpsr: 0x0100001c [00:00:05.591,278] <err> os: Faulting instruction address (r15/pc): 0x0102854a [00:00:05.591,339] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0 [00:00:05.591,369] <err> os: Fault during interrupt handling [00:00:05.591,400] <err> os: Current thread: 0x21006e98 (unknown) [00:00:05.907,012] <err> os: Halting system

Edvin said:

Can you see any advertisements if you scan for nearby devices using your phone (nRF Connect for Android/iOS)?

Can you connect to it? Does it maintain a stable connection?

I can't because CPU_RADIO stopped working due to the assertion. I tested on my B2 to see if it was a Kconfig or overlay that I configured wrong, but on B2 the sample worked.

Best Regards,

Brendow

[Edvin]

Is that the unmodified peripheral_uart sample from NCS v2.9.0?

[brendow]

Yes, I just commented on the lines used by the #include <dk_buttons_and_leds.h> 

	for (;;) {
		// dk_set_led(RUN_STATUS_LED, (++blink_status) % 2);
		k_sleep(K_MSEC(RUN_LED_BLINK_INTERVAL));
	}

because if I didn't do that it would show me a continuous error log:

[00:01:06.631,652] <err> dk_buttons_and_leds: LED index out of the range
[00:01:07.631,835] <err> dk_buttons_and_leds: LED index out of the range
[00:01:08.631,988] <err> dk_buttons_and_leds: LED index out of the range
[00:01:09.632,171] <err> dk_buttons_and_leds: LED index out of the range
[00:01:10.632,324] <err> dk_buttons_and_leds: LED index out of the range
[00:01:11.632,507] <err> dk_buttons_and_leds: LED index out of the range
[00:01:12.632,659] <err> dk_buttons_and_leds: LED index out of the range
[00:01:13.632,843] <err> dk_buttons_and_leds: LED index out of the range
[00:01:14.632,995] <err> dk_buttons_and_leds: LED index out of the range
[00:01:15.633,178] <err> dk_buttons_and_leds: LED index out of the range
[00:01:16.633,331] <err> dk_buttons_and_leds: LED index out of the range

but the rest of the code remains intact