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]

Hi Allan,

Allan-led said:

I still have yet to communicate with the hardware engineer, as he is on vacation, he will be back soon, I will make sure to pass this message along to him as well, thank you so much.

Great!

Allan-led said:

I tried to run the radio test. However, the build fails due to fatal error: pm_config.h: No such file or directory. I have checked out various suggested solutions on the devzone, but I don't think any of them really applies to me. Do you have any idea on how I should go about this problem?

In the log, I see references to TF-M, which should be related to the /ns build target. Do you get the error for both the non-ns and the ns-target? For the nRF54L15DK the full build targets would be nrf54l15dk/nrf54l15/cpuapp and nrf54l15dk/nrf54l15/cpuapp/ns, respectively.

Best regards,

Maria

[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

[Susheel Nuguru]

Hi Allan, 
Maria is sick, So I will try to assist while she is away. 
If you have set CONFIG_SYSTEM_CLOCK_NO_WAIT to yes and still see this issue, then it is either that there might be an actual issue with starting the HFCLK XTAL on your board or this issue might not be related to HFCLK. 

As some more debugging check you can manually try to start it just before mpsl_init and see if the behavior chagnes. Insert some logs and manual starting of HFCLK like below

NRF_CLOCK->TASKS_HFCLKSTART = 1;
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) {}
printk("HFCLK started manually.\n");
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;

mpsl_init();


if (!nrf_clock_hf_is_running(NRF_CLOCK)) {
    printk("HFCLK not running before mpsl_init!\n");
}

This will atleast help us debug in the right direction if the issue is still HFCLK or not.