Interrupt on P1.06 affects the communication between the app core and the network core

[zohan]

Hi everyone,

We found that the LIS2MDL_INT interrupt from the compass on P1.06 affects communication between the app core and the network core.

About 3 seconds after bootup, if we perform a Bluetooth function such as scanning or advertising, it results in a timeout and causes the system to reset, as shown below.

We tried postponing bt_enable(), but it failed because the app core couldn't communicate with the network core.

However, if we select a different compass interrupt, the LSM6DSV_INT1 on P1.04, the Bluetooth function works well.

ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:331
        command opcode 0x200a timeout with err -11
[00:00:20.995,086] <err> os: r0/a1:  0x00000003  r1/a2:  0xfffffffe  r2/a3:  0x20026918
[00:00:21.005,920] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x0007f0e5
[00:00:21.016,723] <err> os:  xpsr:  0x49100000
[00:00:21.024,108] <err> os: s[ 0]:  0x20026bdc  s[ 1]:  0x00000000  s[ 2]:  0x00000014  s[ 3]:  0x0009d811
[00:00:21.036,682] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x000b9e76  s[ 7]:  0x2004d3c4
[00:00:21.049,285] <err> os: s[ 8]:  0x20054a54  s[ 9]:  0x0009ceab  s[10]:  0x000b9e76  s[11]:  0x2004d3c4
[00:00:21.061,859] <err> os: s[12]:  0xfffffff5  s[13]:  0x0007f0e5  s[14]:  0x000b9e76  s[15]:  0x0000200a
[00:00:21.074,401] <err> os: fpscr:  0xfffffff5
[00:00:21.081,756] <err> os: Faulting instruction address (r15/pc): 0x0007f0f0
[00:00:21.091,827] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:21.101,593] <err> os: Current thread: 0x20026918 (main)
[00:00:21.110,260] <err> fatal_error: Resetting system

We use an external clock and added the configuration to prj.conf in both the app core and the network core.

CONFIG_CLOCK_CONTROL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

Has anyone encountered a similar issue? Could there be any specific cause I should check?

Any suggestions would be greatly appreciated. Thanks!

[Maria Gilje]

Hello,

My first point of investigation is if your sensor requires high speed functionality from the pin. Different drive configurations are available for a subset of the GPIO pins. See the table below, which is a screenshot from the nRF5340 PS - Pin assignments.

Since you are testing two different sensors, this makes it hard to evaluate if it is P1.06 which is the issue or if the LSM6DSV does not have the same requirements as the LIS2MDL in terms of drive configuration. I recommend starting out with testing a pin which supports high drive configurations.

Best regards,

Maria

[zohan]

Hi,
During the investigation, we discovered that the pin was left floating, which likely caused the unexpected behavior.
After configuring the pin as pull-down in the Device Tree (DTS), the issue was resolved, and the network core operated as expected.

- irq-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ irq-gpios = <&gpio1 6 GPIO_PULL_DOWN>;

Sincerely,

zohan

[Maria Gilje]

Great to see that you found a solution and thank you for sharing it.