nrfxlib Softdevice Controller crashes (hardfault) on nRF52832 but not on nRF52840 without Zephyr (baremetal)

[Nguyen Hoan Hoang]

Hi, We are trying to work with nrfxlib directly baremetal without Zephyr.  Were able to do advertising with it.  On nRF52832 the SDC crashes when we tried to set new advertising data by calling

sdc_hci_cmd_le_set_adv_data

On the nRF52840, everything works smoothly. 

We saw the debug symbols that the libsoftdevice_controller_multirole.a was compiled for S140.  Could this be the issue.  Can Nordic provide a version for the S132 ?

I aslo suspect other issue.  it could be that some how when compiling for the nRF52832 it cause some global variable inside the lib to be unaligned causing the crash (hardfault).

Please review the library code to make sure proper variable alignment or enable unaligned access for the gcc compiler when compiling the lib.

crash location : sym_OC5GPSERLPE7TKXSCU3QAZ62H3OM4MWFYV7WX2I() at 0x2f5f8

UPDATE : Sorry I was talking to fast about the the nRF52840.  It also crashes but I can confirm this.  The crash was cause by unaligned access within either the mpsl or the sec lib.

Compile my code by disabling all optimization works but not when optimization is enable.  The different is that when no optimization all global vars are word aligned while optimization will pack all global on a byte align. 

Thanks. 

[Amanda Hsieh]

Hii, 

Which version of s132 and s140 you are using? or from which version of NCS?

Regards,
Amanda

[Nguyen Hoan Hoang]

The ones in the nRF5_SDK 17.1

s132_nrf52_7.2.0_softdevice.hex

s140_nrf52_7.2.0_softdevice.hex

The problem isn't the Softdevice.

I believe there are global variables that need aligned access but are not aligned using __ALIGN(x).  So when compiled with optimization.  Those variables become unaligned due to optimization compacting all global on a byte boundary. So you need to force those variables to be word aligned with __ALIGN(x).  That was the cause of the crash inside MPSL & SDC.

  

[Nguyen Hoan Hoang]

that doesn't solve the problem.  you can provide me the source I'll fix it.

[Nguyen Hoan Hoang]

Vidar Berg said:

I don’t quite understand how this can be an alignment issue. Did you check the usage fault register after the fault exception was raised?

FYI

https://exchangetuts.com/unaligned-access-causes-error-on-arm-cortex-m4-1640371864183643

The crash was from a ldr instruction.  Again this is an unaligned access fault problem.

[Vidar Berg]

I'm familiar with alignment problems, but I don't see any clear indication of that being the problem here. That said, I'm not sure if I read the byte order here correctly:

Vidar Berg said:

So it appears that none of the usage fault bits are set, which means the fault is triggered by something else.

The most significant bits belong to the usage fault status register as shown here: https://interrupt.memfault.com/blog/cortex-m-fault-debug#cfsr

[Nguyen Hoan Hoang]

THose bits are relevant only when you get a Memfault.  In this case is a hardfault. Nonetheless, it is the cause by an unalign access and have proved to you.  Please stop arguing and do a code review on your side or you can send me the code.  I will fix it for you.

see the LDR into an unaligned address in R3

[Vidar Berg]

Any chance you could provide me a minimal version of your project so I can try to replicate this here? I'm not trying to be difficult with you, but I need to have something more concrete to go on before I can involve the developers.

Nguyen Hoan Hoang said:

In this case is a hardfault

All fault events detected by the processor will trigger the hardfault exception unless you have enabled the other fault handlers in your code (i.e. Usage fault, memory managment fault, and Bus fault).

Nguyen Hoan Hoang said:

see the LDR into an unaligned address in R3

I do not see where the unaligned access is. The ldrb instruction shown in your screenshot is just loading a byte from memory (RAM) into r3, so this operation can't be unaligned, at least.

From the Cortex M4 Generic user Guide:

(https://developer.arm.com/documentation/dui0553/latest/)

Edit: I can't tell from the screenshots you posted what the r1 value was when the ldrb instruction was executed.

[Nguyen Hoan Hoang]

Newer update of the nrfxlib no longer crashes.  Everything works fine so far.  Advertisement implementation works both legacy 31 bytes and extended adv 255 byte.  Moving on to connections stuff.

For interested parties who want to know how this works.  Full source code available here :

https://github.com/IOsonata/IOsonata/blob/master/ARM/Nordic/nRF52/src/ble_app_sdc.cpp

examples firmware to advertise a counter in private data : 

https://github.com/IOsonata/IOsonata/blob/master/ARM/Nordic/exemples/BleAdvertiser.cpp

This example works with both new SDC and old nRF5_SDK17.