MPSL assert error 112, 2134 when trying to advertise

[jrhaws]

I am trying to set up my application to advertise on the BLE and am having issues with some asserts I am seeing.

The error I am getting is shown here in my serial console:

I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF52x (0x0002)
I: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
I: Identity: E4:40:49:3C:12:84 (random)
I: HCI: version 5.4 (0x0d) revision 0x1077, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x1077
Bluetooth initialized
E: MPSL ASSERT: 112, 2097
E: ***** HARD FAULT *****
E:   Fault escalation (see below)
E: ARCH_EXCEPT with reason 3

E: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000000
E: r3/a4:  0x200058bd r12/ip:  0x00000000 r14/lr:  0x00022b1f
E:  xpsr:  0x61000018
E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
E: s[ 4]:  0x00000002  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
E: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0xffffffff  s[15]:  0x00000000
E: fpscr:  0x0df9bb2d
E: Faulting instruction address (r15/pc): 0x00022b2a
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x20002728 (sysworkq)

What am I doing wrong here?

I looked at this ticket to see if it would help. It indicated the HFCLK may not have been started, but when I put the code in place to test the startup time it never exits the while loop. Maybe this is indicative of a custom hardware issue with that crystal? I did put in the code at the end (a call to mpsl_clock_hfclk_request), but that never calls the clock_started_cb unless I am debugging and slowly stepping through the code.

 MPSL ASSERT: 112, 2134 if using multiple BLE communication 

Thanks for the support!

[ovrebekk]

Hi Jonathan

Which version of the nRF Connect SDK are you using? 

I can't find any references to this particular assert in earlier cases, but if you provide me the SDK version I can see where it originates. 

Have you tried to run any standard examples like the beacon sample or the peripheral_lbs sample to see if you get similar issues?

Best regards
Torbjørn

[jrhaws]

I am running v2.4.0.

I have not run any other samples on this board since my base application that would blink some LEDs seemed to run okay. I can run samples if that will help though. Will either the beacon or peripheral_lbs tell me whether the hardware is okay?

Thanks!

[ovrebekk]

Hi 

Running a standard Bluetooth example should show you whether or not there are some critical issues with the clocks, regulators etc. If it works you don't get a 100% guarantee that there are no issues with the hardware, but if it doesn't work it is a strong indication that there is. 

A connected sample like peripheral_lbs is better than the beacon sample, since running a Bluetooth connection requires stricter timing that simple beaconing and could give an indication if you have issues with the LF clock source for example. 

Is your project based on one of the standard samples or have you built it more or less from the ground up?

Does the configuration of the example differ much from the standard Bluetooth samples?

Best regards
Torbjørn

[jrhaws]

Hi Torbjørn,

I ran the peripheral_lbs example on my custom board and it is failing with similar errors. I did find that after I did a pristine build of the project for the DK it runs just fine on the DK, so no issues there.

So the issue appears the be isoloated to our board. Based on what I am finding with that hardware in debugging this and other issues, I am highly suspicious of the clocks. Would that match your assessment?

To answer your other questions, our application is mostly based on this peripheral_lbs sample in fact, minus the security aspects.

Thanks!

Jon

[ovrebekk]

Hi Jon

Sounds like the issue is hardware related then. 

I agree that investigating the clocks would be a natural first step. 

If it is the HF clock that is the problem it must be pretty serious, possibly the HF crystal is not able to start at all. 

If you are using external LF crystal this could also be the culprit, as this clock is used for the timing of various stack events. 

I think we should start by doing a proper hardware schematic and layout review, and see if we can spot any issues in your design. 

I recommend that you open a new ticket on this to keep the discussion separate, and make sure it gets handled by one of the hardware experts (hardware reviews is not my forte). You can link to this case for context. 

Best regards
Torbjørn

[jrhaws]

After doing more testing, this would only happen rarely. I believe we had a few configuration issues that helped eliminate the errors, but our underlying issue was a missing decoupling capacitor on DEC4, causing all sorts of noise and instability on the internal LDO. We added a cap to ground on that pin and now everything is working just fine.

Thanks for the support!

Jon