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;
}

[Maria Gilje]

Hello,

Thank you for sharing your modified sample. I was able to get this working today.

There is a nRF54L15 specific configuration file for the OpenThread CLI sample which I used parts of to make the modified hello_world work with RTT logging. The symbol choices are documented in the sample.

Add these Kconfig symbols to your prj.conf and start with a fresh build (delete your old directory or use a new name):

CONFIG_MAIN_STACK_SIZE=6144

CONFIG_NVS=n
CONFIG_ZMS=y
CONFIG_SETTINGS_ZMS=y

CONFIG_OPENTHREAD_NORDIC_LIBRARY_COMMON=y

CONFIG_OPENTHREAD_NORDIC_LIBRARY_COMMON can be exchanged with CONFIG_OPENTHREAD_NORDIC_LIBRARY_FTD or CONFIG_OPENTHREAD_NORDIC_LIBRARY_MASTER, as both of those selects CONFIG_OPENTHREAD_NORDIC_LIBRARY_COMMON.

Best regards,

Maria

[Allan-led]

Hi Maria

I tried adjusting my prj.conf, and it looks as follows: 

CONFIG_GPIO=y
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_UART_CONSOLE=n
CONFIG_SERIAL=n
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_GPIO_INIT_PRIORITY=40

CONFIG_SHELL=y
CONFIG_OPENTHREAD_SHELL=y
CONFIG_SHELL_ARGC_MAX=26
CONFIG_SHELL_CMD_BUFF_SIZE=416

CONFIG_OPENTHREAD_NORDIC_LIBRARY_COMMON=y

CONFIG_NET_L2_OPENTHREAD=y
CONFIG_NETWORKING=y

CONFIG_MAIN_STACK_SIZE=6144

CONFIG_NVS=n
CONFIG_ZMS=y
CONFIG_SETTINGS_ZMS=y

However, it would still not print Hello World xx in Segger RTT.

I tried removing CONFIG_NET_L2_OPENTHREAD=y from the updated prj.conf file such that I have:

CONFIG_GPIO=y
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_UART_CONSOLE=n
CONFIG_SERIAL=n
CONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_GPIO_INIT_PRIORITY=40

CONFIG_SHELL=y
CONFIG_OPENTHREAD_SHELL=y
CONFIG_SHELL_ARGC_MAX=26
CONFIG_SHELL_CMD_BUFF_SIZE=416

CONFIG_OPENTHREAD_NORDIC_LIBRARY_COMMON=y

# CONFIG_NET_L2_OPENTHREAD=y
CONFIG_NETWORKING=y

CONFIG_MAIN_STACK_SIZE=6144

CONFIG_NVS=n
CONFIG_ZMS=y
CONFIG_SETTINGS_ZMS=y

and this was still able to print. 

Thus, the problem still has not been solved; the messages will only print if CONFIG_NET_L2_OPENTHREAD is not present. 

Please note again, that I am flashing onto an external module by connecting it to the 54L15dk with programming wires. If I'm only flashing onto the 54L15dk, I can view the messages with no problem, even with CONFIG_NET_L2_OPENTHREAD=y present. 

Thanks for your time, I look forward to your reply!

Best regards,

Allan Wang

[Maria Gilje]

Hey Allan,

Thank you for your update. I will do another trial tomorrow where I use the debug out functionality on the DK to program another DK. This is a bit closer to your setup at least.

I appreciate your patience!

Best regards,

Maria

[Maria Gilje]

Unfortunately my trial did not show any different results.

Could you please share some more details on how you connect the nRF54DK to your module? Does your module have a 10-pin connector?

If you have another DK available which uses the nRF5340 as the Interface MCU, for example the nRF5340 DK, it has another debug out connector which is commonly used for external boards without a 10-pin connector.

Best regards,

Maria

[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