mpsl assert file "107", line 292

[cristic]

Hi guys,

For a client of mine I'm working on an openthread RCP implementation using a SolidRun N8 that contains the NRF52833.

I'm using ncs v2.9.0-nRF54H20-1.

The problem is that after only ~2 minutes of 5 ping packets per second, I get the following assert (seen here in gdb)

Breakpoint 1, m_assert_handler (file=0x20005ebc <z_interrupt_stacks+636> "107", line=292) at /home/cristic/ncs/v2.9.0-nRF54H20-1/nrf/subsys/mpsl/init/mpsl_init.c:304

The code is pretty basic, based on an older sample. It initializes a single instance and runs an endless while:

    while (!otSysPseudoResetWasRequested())
    {
        otTaskletsProcess(instance);
        otSysProcessDrivers(instance);
    }

Here's the full project .config file.

6886.config.txt

Any hint on what I could change to make this work?

[cristic]

Hi Amanda,

As I've explained before I don't have a DK available. My setup is in Israel and nobody delivers there nowadays. Did you try modifying the coprocessor example with the files I attached above and running it on a DK?

The dataset I use is:

> dataset active
dataset active
Active Timestamp: 1
Channel: 15
Channel Mask: 0x07fff800
Ext PAN ID: c0de1ab5c0de1ab5
Mesh Local Prefix: fdde:ad00:beef:0::/64
Network Key: 1234c0de1ab51234c0de1ab51234c0de
Network Name: SleepyEFR32
PAN ID: 0x2222
PSKc: 992c3b39534992571a6a9045db5319e3
Security Policy: 672 onrc 0
Done

I have routereligible disabled and this connects it to a RPI running vanilla OTBR with a Silabs module as RCP. I then run from rpi:

ping -i 0.2 fdde:ad00:beef:0:0:ff:fe00:40f

where 0x040f is the RLOC of the NRF child.

Does this sound simple enough?

[Amanda Hsieh]

Hi Cristian, 

We were unable to reproduce the reported issue.

In the latest NCS release (v3.2.0), the REM scheduler has been reworked. We recommend migrating to this version, as the updated implementation may resolve the issue.

Regards,
Amanda H.

[cristic]

It's been 7 months Amanda. We went with Silicon Labs a long time ago.