sd_clock_hfclk_request() hard fault

[rgrr2]

Hi,

my device does some UART communication. Because temperature drift of HFINT is to large, the external HFXO has to be used. To make things worse, this is a low power device and so HFXO should be started only if UART communication takes place.

Idea is to call sd_clock_hfclk_request() on start of communication and sd_clock_hfclk_release() on end of reception of the response.

Unfortunately sd_clock_hfclk_request() throws a hard fault if called within a RTC2 interrupt context, same valid for the release function - which works if called from the UART interrupt context.

Questions:

1. when and why is this hard fault happening?
2. how to prevent this?
3. when is it safe to call the sd_clock_hfclk_*() functions?
4. how can one determine if the RTC2 interrupt context is active?

Thanks for help / ideas.

Hardy

[MartinBL]

Hi,

Sounds like an interrupt priority or nesting issue. I bet you have RTC2 configured to use a higher interrupt priority than the UART? You cannot call Softdevice APIs (all sd_xx.... functions) from within an interrupt context with priority level 2 or 3 (level 1 on nRF51).

[rgrr2]

Hey Martin, you are right: interrupt prio is three for the RTC and six for the UART. I will change this and check it. Is this behavior documented some where? Hardy

[MartinBL]

It is briefly mentioned in the link I provided:

Note: The priorities of the interrupts reserved by the SoftDevice cannot be changed. This includes the SVC interrupt. Handlers running at a priority level higher than 4 (lower numerical priority value) have neither access to SoftDevice functions nor to application specific SVCs or RTOS functions running at lower priority levels (higher numerical priority values).

The short explanation is that all Softdevice functions are implemented as Supervisory Calls (SVC), formerly known as Software Interrupts (SWI). By design, ARM processors cannot call such SVCs from within a different interrupt context with a higher or equal priority.

[MartinBL]

I was actually unable to find a good explanation of this, neither on our own infocenter, nor on ARM's infocenter, or even by googling the rest of the internet. It is probably one of the most common pitfalls when working with our BLE stack though, so we should probably make a better and more visible warning and documentation about this.

[rgrr2]

Documenting this feature would be great. Question is where to find this tree in the forest. And there is another pitfall related to the interrupt priority: sd_*() calls cannot be made if interrupts are disabled. Another interesting finding.

Anyway thanks for the explanation. It makes things clearer!