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).

[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.