nRF54L15 hits MPSL assert 107,291 on OT Co-Proc sample

[michael.feist.etc]

OS: Ubuntu 24.04.2 LTS
NRF SDK: v3.0.1
NRF Toolchain: v3.0.1
Hardware: NORA B206 (nRF54L15)
Application: nrf/samples/openthread/coprocessor

Hi, I'm trying to bring up the coprocessor sample on the NORA B206 which has a nRF54L15. I've left the application completely unchanged other than a custom board 1 to 1 ripped from the nRF54L15DK. The only changes made for my custom board are:

• Removed spi00 and the corresponding external flash.
• Changed internal HFXO to 15250 fentofarads instead of 15000.
• Changed LFXO to use external caps.
• Board name changes.

I've made sure that the app has no other changes by diffing the files.

The board specific .overlay and .conf for the nRF54L15DK are the exact same but with their names changed to apply to my custom board.

The nRF54L15 is communicating over UART with an IMXRT1064 running the spinel driver.

There are a few things happening:

• `mpsl_init` takes an incredibly long time to execute at startup. This usually takes about a minute after starting debug with a JLink. If I restart from the debugger instead of doing a full stop and start, `mpsl_init` is generally instant.
• After running for a while, while the IMXRT is trying to communicate over UART, a MPSL assert is hit in file 107 line 291. If the IMX is halted, the nRF54L15 never crashes.

Since, as far as I'm aware, MPSL is pre-compiled and closed source, it's almost impossible to reason about what is going wrong.

4341.board.zip

[michael.feist.etc]

I've replicated the problem on the nRF54L15DK now.

On our custom board, we have test points for the TX and RX lines. I hooked the devkit into those.

I'm building the same sample, this time directly from the source tree instead of a copied version. The only modifications were disabling bias-pull-up on the uart20_default pinctrl group, limiting the uart to 115200 instead of 1Mb, and disabling flow control. I've verified that these are the only changes via git diff since they're in the actual repos.

After a while running, the IMX asserts due to a failure in Spinel comms. I know Spinel comms are working at least for a while since it gets past the initialization. I pause the nRF and it's spinning in the Idle thread like normal. However, after pressing continue on the debugger, it immediately jumps to the MPSL assert.

The issue with the slow start up in mpsl_init seems to have gone away with switching to the devkit. It seems like it's probably unrelated to the assert.

[Edvin]

michael.feist.etc said:

After a while running, the IMX asserts due to a failure in Spinel comms. I know Spinel comms are working at least for a while since it gets past the initialization. I pause the nRF and it's spinning in the Idle thread like normal. However, after pressing continue on the debugger, it immediately jumps to the MPSL assert.

If you halt the nRF using the debugger, it cannot expect to continue after this point. There are too many time-critical events that are missed. 

What is the IMX? I am not familiar with this term. Is that the nRF? If so, does it assert (file 107 line 291) before you halt the nRF? Or only after?

Best regards,

Edvin

[michael.feist.etc]

The IMX is the IMXRT1064, the other processor on the other side of the UART.

What causes pausing in the debugger to assert the nRF? It only seems to cause an assert after the Spinel comms have run for a decently long time. I can pause and unpause the debugger as much as I want as long as the IMX isn't talking to it. I can also pause once the UART comms have started without hitting the assert as long as the Spinel connection hasn't been running for too long.

I went and checked if the nRF is asserting if I don't step in with the debugger. It doesn't, I can restart the IMXRT and the Spinel comms will work for a little bit like normal. The assert is only hit after a halt followed by a continue in the debugger.

Regardless of whether I hit an assert, the Spinel communications fall over after probably 10 seconds of running just fine.

[Edvin]

michael.feist.etc said:

I can also pause once the UART comms have started without hitting the assert as long as the Spinel connection hasn't been running for too long.

Yes, that is correct. If no radio protocol has started, you are probably fine stepping through the application.

MPSL assert 107, 291 is rem_sig_stop_Set returning false, so it means that the moment in time is too late to set the stop signal. This can happen if you block an interrupt for too long. If this only happens after you halt the chip, and click "continue", then I would say that this is what is causing it.

Best regards,

Edvin