Application fails to boot on custom board : IPC endpoint bind timed out followed by 802.15.4 serialization error: -6

[abollaert]

Hi,

I've been developing a Matter device based on the nRF5340 SoC, and have been using the DK up until now. We've been developing a custom board in parallel. I've created a board definition for our own board, but when trying to run the application it crashed with a kernel panic indicating there's a 802.15.4 serialization error when it tries to communicate with the net core:

E: IPC endpoint bind timed out

ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/drivers/ieee802154/ieee802154_nrf5.c:1152

802.15.4 serialization error: -6
E: r0/a1:  0x00000004  r1/a2:  0x00000480  r2/a3:  0x20010580␍␊
E: r3/a4:  0x20016af0 r12/ip:  0x00000000 r14/lr:  0x00035983␍␊
E:  xpsr:  0x69100000␍␊
E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000␍␊
E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000␍␊
E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000␍␊
E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000␍␊
E: fpscr:  0x000c1c14␍␊
E: Faulting instruction address (r15/pc): 0x00091790␍␊
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0␍␊
E: Current thread: 0x20010580 (main)␍␊
E: Halting system

When I try running the application on the DK (also using the custom board definition) it does boot correctly.

I'm pretty new to the nRF53 and the multicore setup, so could you give me some pointers as to where to start looking for this problem? Is this a hardware problem, or configuration considering the code does work on a DK?

Kind regards and thanks,

-Alex

[Øivind]

Hi,

Is the correct network core image being included in the build and flashed to the network core?

If you are not sure, could I see the full build log that is generated when you build the application?

[abollaert]

Hi,

yes the net core gets built too (the same build works on the devkit).

I got the image running in the mean time, but I'm not sure why it didn't work before.

The custom board does not have a crystal for the LFCK, so I configured it to use the RC instead like so:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

In the cpu app as well as the rpmsg child image. This works fine on the devkit, but fails to boot on the custom board with the error above (timeout).

I then changed it not to use the RC but instead to derive the LFCK from the HFCK, and then it works properly on the custom board as well:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

I'm happy that it works (seems to cause no issues, it boots, I can get it commissioned and control it through the controller), but I'm at a loss why the RC option didn't work.

Kind regards,

-Alex

[Øivind]

Hm, I'll look into it and get back to you.

Which version of the nRF Connect SDK are you using?

[abollaert]

I'm using the latest version (v2.2.0).

[hugzy123]

We're also seeing this issue on our nRF53840 custom board.

Same conditions as abollaert , no external LFCK, fixed using HFCK by setting CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y.

Internal LFCK works fine on the development kit