Crash on connect with NCS 2.6.0

[m1cha]

You can find all information about the issue and how to produce it on GitHub: github.com/.../ncs-2.6.0-connect-crash

[Simonr]

Hmm, is there a reason you're using this Zephyr advertising API on your end? I don't see it being a great fit with the SoftDevice controller. I'm sorry, but I have not had time to set this up on my end yet but will try to do so tomorrow. It could be MTU related it seems, so could it be that the MTU sizes are invalid when disabling the extended advertising config and trying to enable the UART service? 

I still think using the command window in your build folder and the following command to get a file name and line number for that address could be helpful, so please give it a try in the meantime: arm-none-eabi-addr2line -e _build/zephyr/zephyr.elf 0xbb74.

Best regards,

Simon

[m1cha]

Sry, that I missed your question about addr2line. There is no line information for that closed-source function, but it's from nrfxlib/mpsl/lib/cortex-m4/soft-float/libmpsl.a and this is the relevant objdump:

0000bb5c <sym_DQONLUECJTIEYFOFJXXAPJO4POIAJKJNKBGVN5A>:
    bb5c:       ea81 0300       eor.w   r3, r1, r0
    bb60:       079b            lsls    r3, r3, #30
    bb62:       e92d 41f0       stmdb   sp!, {r4, r5, r6, r7, r8, lr}
    bb66:       d15d            bne.n   bc24 <sym_DQONLUECJTIEYFOFJXXAPJO4POIAJKJNKBGVN5A+0xc8>
    bb68:       0787            lsls    r7, r0, #30
    bb6a:       d05f            beq.n   bc2c <sym_DQONLUECJTIEYFOFJXXAPJO4POIAJKJNKBGVN5A+0xd0>
    bb6c:       2a00            cmp     r2, #0
    bb6e:       d057            beq.n   bc20 <sym_DQONLUECJTIEYFOFJXXAPJO4POIAJKJNKBGVN5A+0xc4>
    bb70:       4603            mov     r3, r0
    bb72:       e001            b.n     bb78 <sym_DQONLUECJTIEYFOFJXXAPJO4POIAJKJNKBGVN5A+0x1c>
    bb74:       2a00            cmp     r2, #0
    bb76:       d053            beq.n   bc20 <sym_DQONLUECJTIEYFOFJXXAPJO4POIAJKJNKBGVN5A+0xc4>

[m1cha]

And some more questions I forgot to answer

> Hmm, is there a reason you're using this Zephyr advertising API on your end? I don't see it being a great fit with the SoftDevice controller.

I see it the other way around: We don't need and don't want to use extended advertising due to incompatibility with certain centrals. There is no reason for us to enable or use that API and it might save flash size(which not an important reason though).

> It could be MTU related it seems, so could it be that the MTU sizes are invalid when disabling the extended advertising config and trying to enable the UART service?

I don't know, but isn't that handled by zephyr internally? The only thing we can do is to set some limits using kconfigs and accept or reject a centrals change request using one of the connection callbacks.