Soft Device Controller hard fault - NULL pointer dereference in library

[sss]

We are investigating the use of the Soft Device Controller as an alternative to a Soft Device for our production product. Using our BLE stack we have successfully completed a BLE scan using the SDC library.

However, now that we are trying to send advertisements we are getting a hard fault within the Nordic library. The symbols are obfuscated so debugging is difficult.

After we start advertising, the following is what we have managed to ascertain:

    MPSL_IRQ_TIMER0_Handler()
    ...
    sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A()
      -> reads NULL from RAM
      -> deferences NULL
      -> bx to 0x20040000
      -> hardfault

The symbol sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A is presumably a function that takes a function pointer as one of its arguments (or maybe a pointer to a function pointer). However, for some reason it is receiving a NULL pointer and not checking before calling it.

Here is the relevant assembly:

0x150fc <sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A>           ldr     r1, [pc, #8]    ; (0x15108)
0x150fe <sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A+2>         str     r0, [r1, #0]
0x15100 <sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A+4>         ldr     r1, [r1, #8]
0x15102 <sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A+6>         ldr     r1, [r1, #0]
0x15104 <sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A+8>         bx      r1   

r0             0x2000a304          536912644
r1             0x200004c8          536872136
r2             0x16469             91241
r3             0x0                 0
r4             0x2000a304          536912644
r5             0x2000065c          536872540
r6             0xe000e000          3758153728
r7             0x100               256
r8             0x0                 0
r9             0x0                 0
r10            0x2ce9c             183964
r11            0x2ce9f             183967
r12            0x200013ac          536875948
sp             0x20037690          0x20037690
lr             0x16489             91273
pc             0x150fe             0x150fe <sym_PY5KUATPBYOYJBMP6H7AVRPSEO7BZX2JK524O6A+2>
xpsr           0x81070018          2164719640
msp            0x20037690          537097872
psp            0x0                 0
primask        0x0                 0
basepri        0x0                 0
faultmask      0x0                 0
control        0x0                 0
fpscr          0x0                 0

I am hoping that with the provided symbol you'll have some hints as to what might be happening.

[Susheel Nuguru]

The symbol should be for ll_adv_prepare but we are not able to understand the full context of this due to the obfuscated call stack.

Are you using advertising extensions? and could you also give some code snippets on how you are initializing the advertising parameters?

[sss]

Thanks for clarifying, this helped significantly in narrowing the scope of our investigation.

We were calling sdc_support_ext_adv() with the peripheral library linked in - which should have yielded an error from the API, but didn't. In 1.9.1 or thereabouts, this appears to have been resolved and it will instead report NRF_EOPNOTSUPP as expected. Now we are using sdc_support_adv() with the peripheral library and everything is working as expected. Thanks for your help.