CONFIG_NET_L2_OPENTHREAD=y leads to failure in gpio pins.

[Allan-led]

Hi,

I noticed an issue with CONFIG_NET_L2_OPENTHREAD=y in my project, and I prepared a newer, simpler project to investigate in the issue.

The new program simply sets pins to high and low. After flashing it onto an external module and plugging the external module onto a baseboard, all of the LEDs on the base board should be flashing one by one in a cycle..

As I slowly add more configurations to prj.conf, I realize that adding CONFIG_NET_L2_OPENTHREAD=y when CONFIG_NETWORKING=y will lead to all the external module pins behaving unexpectedly. None of the LEDs on the base board will turn on. What does CONFIG_NET_L2_OPENTHREAD do exactly? How does it interfere with the gpio pins? 

[Maria Gilje]

Hello,

What does CONFIG_NET_L2_OPENTHREAD do exactly?

Some documentation on the OpenThread L2 abstraction level can be found here: https://docs.nordicsemi.com/bundle/zephyr-apis-latest/page/group_ieee802154.html

CONFIG_NET_L2_OPENTHREAD also selects a list of other Kconfig symbols. See the list here:

https://docs.nordicsemi.com/bundle/ncs-latest/page/kconfig/index.html#CONFIG_NET_L2_OPENTHREAD

How does it interfere with the gpio pins? 

I need to investigate this. Your simple project may help to speed up the process, but it looks like you are using a custom board. Are you able to reproduce the issue on an nRF54L15 DK?

Best regards,

Maria

[Allan-led]

Hi Maria, 

Just an update, I updated my project to an even simpler one, it will just print Hello World + iteration number over and over again. I can view the message through RTT when CONFIG_NET_L2_OPENTHREAD is not enabled. However, I tried enabling the configuration, I can no longer view the messages. Thus, this might be something more significant than just having a conflict with the GPIO pins, as RTTs will not even display any messages. 

#include <stdio.h>
#include <zephyr/kernel.h>
int main() {
	int i = 0;
	while (1) {
		printk("Hello World! %d\n", i++);
		k_msleep(1000);
	}
	return 1;
}

[Allan-led]

Here is my setup. drive.google.com/.../view

Unfortunately I do not have access to another DK that uses the nRF5340 as the Interface MCU.

[Allan-led]

Hi Maria,

I had a chance to try my program with the debugger just now. I was debugging my hello world code with CONFIG_NET_L2_OPENTHREAD=y. I believe my code got stuck at this point (I pressed pause and it led me here)

err = mpsl_init(&clock_cfg, CONFIG_MPSL_LOW_PRIO_IRQN, m_assert_handler);

Are you able to tell anything from this? Please update me on it if you have time to take a look at this, thanks!

Best regards,

Allan

[Allan-led]

Furthermore, I set a breakpoint behind this line of code. It does not reach the new breakpoint. Could there be an issue with how the hardware of my external module was designed?

[Maria Gilje]

Allan-led said:

err = mpsl_init(&clock_cfg, CONFIG_MPSL_LOW_PRIO_IRQN, m_assert_handler);

Are you able to see what the return value from mpsl_init is? Is it an error (-NRF_EPERM or -NRF_EINVAL) or a success code?

Allan-led said:

Are you able to tell anything from this? Please update me on it if you have time to take a look at this, thanks!

Other than finding out the return code I can't tell much from this no.

I'll be able to get some debugging tips early next week!

Allan-led said:

Could there be an issue with how the hardware of my external module was designed?

Maybe. Is your module a commercially available one or is it custom to you and not yet on the market?

If it is custom -- and you haven't done the following before -- we offer hardware reviews here on DevZone. Just post your schematics/layout files in a new private ticket and then one of our hardware engineers can review them.

Best regards,

Maria

[Allan-led]

Hi Maria,

The value of the err variable is 0, as shown in the picture below. However, I don't think this is the expected retval, as it should be able to at least execute or evaluate the next line (396), but no matter how I work with the debugger, it will not jump further. From my experience I feel like it is likely that the mpsl_init function never returned, thus the err value stayed as 0. This also matches the behaviour of the debugger, as when I press continue or step over, it just gets stuck in a stale state and does not show the next breakpoint or the line being executed. Only when I press pause, does it highlight the line as shown below. 

I'm wondering if it is possible to get blocked or stuck in an infinite while loop in mpsl_init? 

The module that I'm working with is a custom one, and it isn't commercially available. 

I look forward to your reply.

Best regards,

Allan Wang