I have been tearing my hair over a really odd behaviour... We are using an nRF52811 based module that interfaces with another microcontroller via SPI. The 52811 is the SPI slave in the setup, and the microcontroller sends data about once per second.
During startup (a few seconds), we also use the UART (to talk to a third micro...), but once normal operation starts, we shut down the UART and call nrf_drv_clock_hfclk_release() to allow the nRF52811 to (a) switch off the crystal, and (b) switch off the HFCLK during idle times.
This works completely as expected, and once the UART is shut down, current consumption is down to a few microamps --- exactly as required. UNTIL the SPI master sends the next SPI transaction. Following that transaction, the HFCLCK will be continuously on, and current consumption is around 400 microamps! That holds true even if the SPIS peripheral gets disabled in response to that communication. However, if gets disabled before receiving the communication, current consumption stays low as expected (but of course, that is just for diagnostics, to rule out reasons unrelated to the SPIS peripheral. In real world usage, we of course need to receive the data from the other micro).
What makes this really bizarre is that enabling the UART in response to one SPI communication, and then disabling it again in response to the next one, will re-establish the "good", i.e. low power state. But, again, only until the next SPI communication happens. This holds true even when the UART is enabled without requesting the crystal clock.
It appears as if the SPIS peripheral fails to relinquish HFCLK if it was the peripheral responsible for having that clock started. If the clock is already running due to the UART, then disabling the UART in response to the SPIS transaction will result in HFCLK being off; If the UART wasn't running, even starting and stopping it won't help. However, I tried using TIMER1 instead of the UART, and it did not cause the same effect. However, it demonstrated clearly that the extra current consumption is due to HFCLK, because running the timer did not cause significant extra current unless the UART-trickery had re-established the "good" state.
After many hours of chasing this issue, I am at a complete loss. This is a serious problem for us, because 400 microamps is more than the power budget for the complete device, so it being wasted by the SPIS peripheral is a definite showstopper 
Any ideas?
P.S.: In all of the above, read "enabling the UART" as "enabling the UART for RX". Just enabling it without starting the RX task is not enough to cause the "healing effect".
