CONFIG_NET_L2_OPENTHREAD=y leads to failure in gpio pins.

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? 

Parents Reply
  • 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

Children
  • 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

Related