What are the conditions that produce an MPSL ASSERT 112, 2105 ?

[laurentc]

Hello, anyone.

On a NRF52840DK, modified to match my target. Using nrf SDK v2.1.0.

I have bluetooth (config for firmware upgrade by BT) advertize smp, have connection and notifs seemingly working

I am having a MPSL ASSERT 112, 2105 as soon as the fw upgrade starts.

What are the conditions that produce an MPSL ASSERT 112, 2105 ?

I know that it fundamentally has to do with conflicting configurations that I am fighting with for eons now.

Could you please publish the exhaustive list of MPSL ASSERT x,y. We would gain some dev time.

[laurentc]

Here are the logs Using nrf logger 

Device Manager, 2023-09-26

Lynx-R1 HST (Device Manager)

I17:27:02.271[j] Connected to E6:C4:DA:D4:02:8A

I17:27:02.567[j] Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)

I17:27:02.627[j] PHY updated (TX: LE 2M, RX: LE 2M)

I17:27:02.966[j] Services discovered

I17:27:03.041[j] Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms)

I17:27:03.110[j] MTU changed to: 252

I17:27:03.287[j] Data written to descr. 00002902-0000-1000-8000-00805f9b34fb

I17:27:03.306[j] Notifications enabled

I17:27:03.329[j] Data written to da2e7828-fbce-4e01-ae9e-261174997c48

I17:27:03.427[j] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-06-00-00-FF-06-BF-62-72-63-08-FF

I17:27:03.448[j] Wait for value changed complete

I17:27:03.500[j] Received Header (Op: 1, Flags: 0, Len: 6, Group: 0, Seq: 255, Command: 6) CBOR {"rc":8}

I17:27:03.528[j] PHY read (TX: LE 2M, RX: LE 2M)

I17:27:03.566[j] Sending (19 bytes) Header (Op: 2, Flags: 0, Len: 11, Group: 0, Seq: 0, Command: 0) CBOR {"d":"Hello!"}

I17:27:03.596[j] Data written to da2e7828-fbce-4e01-ae9e-261174997c48

I17:27:03.617[j] Sending (10 bytes) Header (Op: 0, Flags: 0, Len: 2, Group: 0, Seq: 1, Command: 6) CBOR {}

I17:27:03.640[j] Data written to da2e7828-fbce-4e01-ae9e-261174997c48

I17:27:03.660[j] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 03-00-00-0B-00-00-00-00-BF-61-72-66-48-65-6C-6C-6F-21-FF

I17:27:03.681[j] Received Header (Op: 3, Flags: 0, Len: 11, Group: 0, Seq: 0, Command: 0) CBOR {"r":"Hello!"}

I17:27:03.712[j] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-06-00-00-01-06-BF-62-72-63-08-FF

I17:27:03.810[j] Received Header (Op: 1, Flags: 0, Len: 6, Group: 0, Seq: 1, Command: 6) CBOR {"rc":8}

I17:27:07.422[j] Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 420ms)

V17:29:24.837[l] Starting DFU, mode: CONFIRM_ONLY

I17:29:25.045[j] Sending (10 bytes) Header (Op: 0, Flags: 0, Len: 2, Group: 1, Seq: 2, Command: 0) CBOR {}

I17:29:25.063[j] Data written to da2e7828-fbce-4e01-ae9e-261174997c48

I17:29:25.123[j] Connection parameters updated (interval: 15.0ms, latency: 0, timeout: 20000ms)

I17:29:25.141[j] Notification received from da2e7828-fbce-4e01-ae9e-261174997c48, value: (0x) 01-00-00-86-00-01-02-00-BF-66-69-6D-61-67-65-73-9F-BF-64-73-6C-6F-74-00-67-76-65-72-73-69-6F-6E-65-30-2E-30-2E-30-64-68-61-73-68-58-20-E2-53-41-E1-19-CE-20-97-49-E7-4D-03-5E-93-0B-3F-3E-94-C6-6D-49-84-3E-97-AC-E8-8F-86-57-E4-78-C9-68-62-6F-6F-74-61-62-6C-65-F5-67-70-65-6E-64-69-6E-67-F4-69-63-6F-6E-66-69-72-6D-65-64-F5-66-61-63-74-69-76-65-F5-69-70-65-72-6D-61-6E-65-6E-74-F4-FF-FF-6B-73-70-6C-69-74-53-74-61-74-75-73-00-FF

I17:29:25.159[j] Received Header (Op: 1, Flags: 0, Len: 134, Group: 1, Seq: 2, Command: 0) CBOR {"images":[{"slot":0,"version":"0.0.0","hash":"4lNB4RnOIJdJ500DXpMLPz6Uxm1JhD6XrOiPhlfkeMk=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false}],"splitStatus":0}

V17:29:25.194[k] Validation response: {"images":[{"slot":0,"version":"0.0.0","hash":"4lNB4RnOIJdJ500DXpMLPz6Uxm1JhD6XrOiPhlfkeMk=","bootable":true,"pending":false,"confirmed":true,"active":true,"permanent":false}],"splitStatus":0}

V17:29:25.209[l] Moving from state VALIDATE to state UPLOAD

I17:29:25.231Uploading firmware...

then the board goes into MPSL ASSERT 112, 2105

W17:29:45.274[j] Error: (0x8): GATT CONN TIMEOUT

W17:29:45.418[Uploader] Uploader write failure for chunk with offset=0: m2.b

W17:29:50.515[j] Error: (0x85): GATT ERROR

W17:29:56.331[j] Error: (0x85): GATT ERROR

W17:30:02.101[j] Error: (0x85): GATT ERROR

W17:30:07.907[j] Error: (0x85): GATT ERROR

W17:30:07.945[j] Connection attempt timed out

W17:30:07.974[Uploader] Uploader write failure for chunk with offset=0: GATT ERROR

W17:30:13.051[j] Error: (0x85): GATT ERROR

W17:30:18.837[j] Error: (0x85): GATT ERROR

W17:30:24.731[j] Error: (0x85): GATT ERROR

W17:30:30.638[j] Error: (0x85): GATT ERROR

W17:30:30.669[j] Connection attempt timed out

W17:30:30.719[Uploader] Uploader write failure for chunk with offset=0: GATT ERROR

W17:30:35.810[j] Error: (0x85): GATT ERROR

W17:30:41.693[j] Error: (0x85): GATT ERROR

W17:30:47.575[j] Error: (0x85): GATT ERROR

W17:30:53.459[j] Error: (0x85): GATT ERROR

W17:30:53.491[j] Connection attempt timed out

W17:30:53.546[Uploader] Uploader write failure for chunk with offset=0: GATT ERROR

W17:30:58.649[j] Error: (0x85): GATT ERROR

W17:31:04.512[j] Error: (0x85): GATT ERROR

W17:31:07.054Upgrade cancelled

W17:31:10.296[j] Error: (0x85): GATT ERROR

W17:31:16.061[j] Error: (0x85): GATT ERROR

W17:31:16.096[j] Connection attempt timed out

[Raoul]

Hi Laurent,

I don't have the exhaustive list either, unfortunately. I've asked the MPSL team and will get back to you when I know more.

Could you please publish the exhaustive list of MPSL ASSERT x,y. We would gain some dev time.

I understand that this would be useful, but as far as I know there are no plans to publish this. Still, I've passed on your request!

Best regards,

Raoul

[laurentc]

Thank you for your diligence !

[Raoul]

Hi Laurent,

I heard back from our MPSL team:

Regarding the list of MPSL asserts: We don't have such a list internally, and also these assert codes can be different for each new NCS release. Also, each assert can have many different reasons so unfortunately I don't think there is convenient way to share such a list with customers, it will be basically unusable.

Regarding the issue itself, they are asking for some clarification:

1) Is the customer disabling interrupts in their application for some reason?
2) Is the customer writing to flash or is he doing some other time-consuming operations?
3) Can they share their prj.conf files to check if they have the correct settings?

Could you expand on this, and also share your config files?

I know that it fundamentally has to do with conflicting configurations that I am fighting with for eons now.

Are you suspecting some kconfig options in particular?

Thanks.

Best regards,

Raoul

[laurentc]

If you don't mind, I continue the discussion in our private thread that already exists about the same subject. Titled "Need to postpone inits (like SYS_INIT hidden everywhere) so that my device can do either bluetooth or radio_test or other protocols and switch."