SoftDevice hard fault while porting to mesh

[mdh]

Using S132 v7.2, I'm getting a hard fault at PC 0x00015810 (I see the flag set in SEGGER, and the console outputs a SOFTDEVICE ASSERT FAILED error) that I'm working on manually tracing. I'm borrowing some code from another project of ours to get this one set up, and so the problem is likely something to do with initial mesh setup and initialization that is then causing the later hard fault. I'm hoping I can get the actual assert error information to better pinpoint the problem, because it's been a bit of a wild goose chase up to now.

[tesc]

Hi,

This assert is most likely the mesh stack failing to give the radio back to the SoftDevice in time (i.e. overstaying the timeslot.)

First thing to check would be interrupt priorities: Have you configured the mesh stack correctly? Are you calling any of the mesh stack API from the wrong context? Also, are you by any chance using timeslots yourself, or disabling interrupts anywhere?

Regards,
Terje

[mdh]

Tusen takk Terje. I'll look into those and make sure they're all set up correctly.

[tesc]

Hi,

Did you find anything related to interrupts, or are there still issues to be solved?

Regards,
Terje

[mdh]

Still hunting around - I'm somewhat new on this project and still learning the ropes of both FreeRTOS and the SDKs.

[tesc]

Hi,

Right. Is this a project mixing nRF5 SDK and nRF5 SDK for Mesh? If so, i recommend having a look at Integrating Bluetooth mesh into nRF5 SDK examples.

If FreeRTOS is also part of the mix, then I am afraid things might get a bit more complicated and take some more time for me to answer. Feel free to ask anyway, if something is unclear.

Regards,
Terje

[mdh]

Terje, here's a screenshot of the details I pulled from Ozone. I enabled every fault handler that I could that still reproduced the original error (the UNALIGN_TRP is caught several times if I enable it, but the primary HardFault isn't generated), and I find myself a bit confused, because as best as I can tell, I'm getting an unspecified HardFault that's not a Usage, Memory, or BusFault. I'm digging through the refs you just sent - to clarify, this is a project currently using the nRF5 SDK that's being ported to exclusively use mesh. It also includes FreeRTOS, which has definitely complicated things.

[Kevin Rees]

A SoftDevice assertion isn't necessarily a HardFault (it almost certainly isn't in fact, because HardFaults come through a separate handler I believe). It just means that the SD error checking has caught a state it doesn't think should happen, so it propagates up to the application handler (that was registered on initialization)

[mdh]

tesc, we were able to resolve this issue by altering the setting of NRF_SDH_CLOCK_LF_ACCURACY from 7 down to 4 to loosen up timing requirements.

[tesc]

Hi,

Thank you for the update. Yes, that could actually be the issue. If the clock accuracy settings are better than what you actually have, that could very well lead to issues. As noted by @kevin-rees this is not a hardfault, but rather the SoftDevice asserting. (In this instance the SoftDevice detected that timing requirements were not met, jeopardizing Bluetooth specification compliance.)

You might want to look into that accuracy. Depending on LF clock source, check that you are using the correct:

• capacitance (in case of external xtal; note that correct component values varies depending on xtal.) See the Crystal Oscillator Design Considerations White Paper.
• NRF_SDH_CLOCK_LF_RC_TEMP and NRF_SDH_CLOCK_LF_RC_CTIV (in case of internal RC oscillator.)

Regards,
Terje