BLE Mesh node resets with 'mpsl_init: MPSL ASSERT: 112, 1622'

RE: BLE Mesh node resets with 'mpsl_init: MPSL ASSERT: 112, 1622'

Elfving — Tue, 25 Feb 2025 11:29:13 GMT

Hi again,

The relevant R&D team on our side has tried reproducing what you see with the default sample on DKs, and do not observe what you are describing. (Generic on-off server functionality with e.g. transition time set to 3s, and delay 100ms. A led on the DK dims back and forth.)

I assume then that it is the HFXO that is at fault.

Regards,

Elfving

RE: BLE Mesh node resets with 'mpsl_init: MPSL ASSERT: 112, 1622'

Elfving — Tue, 25 Feb 2025 08:37:03 GMT

Could you expand on why you are using rc1 btw?

[quote user="TechSW"]

Regarding the question about the interrupts, we didn't change anything from the provided example.

[/quote]

Is that the case regarding the sample as a whole, or just the use of interrupts?

I assume then that you do not disable interrupts with __disable_irq(), using additional interrupts with extremely high priority or anything like that.

You are seeing this on multiple nodes right? Not just on one physical device?

Regards,

Elfving

RE: BLE Mesh node resets with 'mpsl_init: MPSL ASSERT: 112, 1622'

TechSW — Mon, 24 Feb 2025 15:58:39 GMT

Dear Elfving,

Thank you for your answer. We are double-checking the HFXO as for your suggestion.

However, we have one more element: apparently, this problem only (or mostly) happens when the light node is configured with mode-on, which means, the light LC server modulates the lightness based on the received LUX messages. It seems that if we disable such functionality, the reset stops to occur (or less likely, need more time to confirm).

Regarding the question about the interrupts, we didn't change anything from the provided example.

Best,

TSW

RE: BLE Mesh node resets with 'mpsl_init: MPSL ASSERT: 112, 1622'

Elfving — Mon, 24 Feb 2025 12:49:33 GMT

Hi,

First off I would like to mention that the rc1 might not be the most optimal for a product. We prefer to use the stable tags for those, like 2.7.0 now that it is out. Though I assume you made a product at a time where you were forced to use 2.7-rc1. It is probably fine either way, I just had to mention it.

I'll look into what the error code is referring to exactly. Though it looks like it is related to timing or the hardware here, maybe the HFXO. There have been some similar cases in the past in which the HFXO wasn't soldered on well enough, or started up correctly. Are you doing a lot of work in interrupts, that could potentially be problematic in regards to timing priorities?

Regards,

Elfving