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]

Hi Maria,

My current project uses /ns as the build target, that's why it was my go-to choice. I have switched to the target without ns and it worked out great. 

However, I am unable to get the program to run properly. I used the debugger and the code got stuck once again at a clock related function. Main calls clock_init(), and I got this error during the call to it:

I have tried the radio test sample code on my 54L15 dK and it works fine, only the module fails due to clock related issues. 

Thank you for your advice!

Best regards,

Allan 

[Maria Gilje]

Hi Allan,

Allan-led said:

However, I am unable to get the program to run properly. I used the debugger and the code got stuck once again at a clock related function. Main calls clock_init(), and I got this error during the call to it:

This could also be related to if the module has an external LFXO or not. If it does not, you need to enable CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC. If the module has an external LFXO, the needed Kconfig symbol is CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL.

Best regards,

Maria

[Allan-led]

Hi Maria,

Since I'm not the most familiar with the hardware design, I just tried enabling the two configurations mentioned above individually. However, neither of them have resolved the clock initialization issue. I am nearly certain that this is an issue with our custom modules, and I will update the hardware engineer with everything once he comes back from vacation in 2 days. 

I appreciate your patience, thanks!

Best regards,

Allan

[Maria Gilje]

Hi Allan,

Allan-led said:

Since I'm not the most familiar with the hardware design, I just tried enabling the two configurations mentioned above individually. However, neither of them have resolved the clock initialization issue.

Thanks for trying.

Allan-led said:

I am nearly certain that this is an issue with our custom modules, and I will update the hardware engineer with everything once he comes back from vacation in 2 days. 

Sounds good!

Best regards,

Maria

[Allan-led]

Hi Maria, 

I have submitted a private ticket at https://devzone.nordicsemi.com/support/343150.

Also, I have found this in the documentations of the mpsl_init function:

 * @note If `CONFIG_SYSTEM_CLOCK_NO_WAIT` is set to 0,
 *       never modify the SEVONPEND flag in the SCR register,
 *       while this function is executing.
 *       Doing so might lead to a deadlock.

I believe according to the documentations, the only way to get stuck in a deadlock would be when CONFIG_SYSTEM_CLOCK_NO_WAIT is set to 0 AND ...

Thus, I tried to set CONFIG_SYSTEM_CLOCK_NO_WAIT to y, such that it doesn't have a value of 0, but it still gets stuck at mpsl_init during execution and it never returns. 

The hardware engineer also said it could be running the debugger on the development kit is different from running the debugger on our custom modules, as there is a specific section on the 54L15dK that is marked as debugger, so we don't know for sure whether the debugging on our custom modules give the right results? Could this be possible?

Best regards,

Allan Wang