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?

[Sigurd]

Hi,

that contains the NRF52833.

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

The release you are using is for nRF54H20 only. It's not a qualified release for nRF52833.

Please use e.g. NCS v2.9.2 instead, and see if that solves your issue.

[cristic]

HI Sigurd,

Thanks a lot for the reply and pointing out the version problem. That was the latest release when I started working with it.

I have switched to v2.9.2 and I get the same behavior.

(gdb) bt
#0  m_assert_handler (file=0x20005ebc <z_interrupt_stacks+636> "107", line=292) at /home/cristic/ncs/v2.9.2/nrf/subsys/mpsl/init/mpsl_init.c:304
#1  0x000035e0 in sym_S2UAPMFVIQXDUOA6CV7GJMB33TYHEUH5D6LHO5Q ()

8358.config.txt

From what I understand it happens during RTC0 interrupt handling. Is there something in my clock configuration that is wrong?

[Sigurd]

Hi!

Are you blocking interrupts for some longer time (3us or more) ?

[cristic]

Hi Sigurd,

I'm not doing that explicitly. I'm just calling those two OT APIs in a loop as listed above. Not playing with irq_lock() at all. I assume that's what you're asking about, not blocking a specific interrupt.

The trigger for the problem is radio traffic. The more traffic, the faster it happens. This device is working as a child to a router and I'm using IPv6 ping from the router towards this device to generate traffic. With 1 ping per second the problem appears after ~5 minutes, with 5 pings per second it appears in under 2 minutes. Without the pings it can hold for hours. So the device does both Rx and Tx, ping packets seem to be ~100 bytes, rssi:-58, channel 15.

The other device under stress is, I guess, the UART0 used to connect to the ot-daemon on the host (at 2Mbit baudrate). There's no logging.

Just trying to list things that could hog the CPU in interrupt context.

Is that 3us hardcoded? Any workaround I could try?

[Sigurd]

Hi!

It would be helpful if we were able to reproduce the issue here on a DK.

1) Are you able to reproduce the issue based on some of our samples in NCS? (If yes, which one, how to build it, etc.)

2) Are you able to reproduce the issue on a nRF52833-DK ?