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,

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.

[Allan-led]

Hi Susheel,

I have added some code in mpsl_init.c from the SDK (currently I'm using 2.9.1)

I have noticed some issues: NRF_CLOCK_Type does not provide fields: TASKS_HFCLKSTART and EVENTS_HFCLKSTARTED. This was a little surprising to me, as I have found some extra documentations at https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/struct_n_r_f_c_l_o_c_k_type.html#details

and it clearly states that these should be available. Below is an image (the insert code functionality does not work right now for some reason) of the NRF_CLOCK_Type def in C:\ncs\v2.9.1\modules\hal\nordic\nrfx\mdk\nrf54l15_types.h, it has never been modified since my download:

==============================================

I figured the closest things would be TASKS_XOSTART and EVENTS_XOSTARTED, and modified mpsl_init.c in the SDK as follows: 

===============================================

So I decided to run my program (a program that simply initializes an ot_instance and starts it) on the 54L15DK, and it worked out fine. 

The above are outputs of the program on my 54L15 development board, the program runs without significant issues and the HFCLK started manually log is present. (the spi_nor has been there on and off, I have trouble controlling it, so I would appreciate it if you could also provide some insights on this)

==============================================

Then, I tried running the same program on our custom module: 

No outputs are present, the program probably didn't get past the while loop that we set up that waits for the crystal oscillator to start.

So I tried using the debugger to debug the module:

The program is indeed stuck at the new line where we created the new while loop. I tried clicking continue, step over, and step into, and none of them would guide me to the next breakpoint (the line right after). I can only press pause to get the debugger to land on the highlighted line, which is the while loop. 

What can we infer from these tests? Look forward to your response!

Best regards,

Allan Wang

[Allan-led]

An update on this as well,

We measured the crystals with an oscilloscope. The low frequency one works as expected, but the high frequency crystal never shows meaningful waves. 

The low frequency one operates as expected, other than when it gets stuck in a deadlock waiting for the high frequency external crystal to be enabled. 

We can detect changes in the voltage of high frequency external crystals, but we have never detected waves on it. 

Best regards,

Allan Wang