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]

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

[Maria Gilje]

Hey Allan,

Allan-led said:

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

This note indicates that it is possible to cause a deadlock, but it seems unlikely that this is happening. If CONFIG_SYSTEM_CLOCK_NO_WAIT is non-zero, the note is not relevant at all.

Errata 39 could potentially be a cause for the behaviour, and a workaround was introduced in nRF Connect SDK v2.9.1. Please to a trial with v2.9.1 and let me know if you see any difference.

Allan-led said:

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

Alright. Do you know if Nordic has performed a hardware review of that module?

Best regards,

Maria

[Allan-led]

Hi Maria,

Thanks for your insights. I just completed a trial with v2.9.1. However, I don't think there are any differences, I'm still getting stuck at the same place in the program. 

I don't think Nordic has performed hardware review. I will contact the hardware engineer about this. Thank you.

Best regards,

Allan Wang

[Maria Gilje]

Hey Allan,

Allan-led said:

Thanks for your insights. I just completed a trial with v2.9.1. However, I don't think there are any differences, I'm still getting stuck at the same place in the program. 

Thank you for testing with v2.9.1.

I'll post an internal ticket to try to get some more insights into what the source issue could be.

Allan-led said:

I don't think Nordic has performed hardware review. I will contact the hardware engineer about this. Thank you.

I look forward to your update on this.

Best regards,

Maria

[Maria Gilje]

Hi Allan,

In my internal ticket this was addressed:

sym_GYXW4XY25R4ELPOOTEBFKAUAI3X7A5AGZZV7OTI is visible in the callstack, which is from the clock init function. If the High-frequency crystal oscillator (HFXO) is not tuned, the EVENTS_XOTUNED signal will stay at 0, which can lead to an endless loop if the HFXO is never tuned.

This feedback leads to a few investigation points: 

• Does your module have an external crystal? One is needed for the HFXO.
• Does the radio function on your custom module? You can test the radio with the Radio test sample.
  

Best regards,

Maria