RE: nRF52840 SPIM3, HFCLK, and anomaly 244

Jared — Tue, 02 Nov 2021 11:21:03 GMT

Hi there!

[quote user=""]We're not using it in QSPI mode but I bet that it applied to non-QSPI SPIM3 too, and I think I was right. Now when we prepare to do any SPIM3 transfer, we call sd_clock_hfclk_is_running() to see if HFCLK is "running" (which I think actually means it's using HFXO), and if it's not running, we call sd_clock_hfclk_request(). This seems to have fixed the issue, but I just wanted to make sure I'm approaching the workaround correctly.[/quote]

This is a reasonable conclusion, and I would say that manually enabling the HFXO seems like the correct workaround for your case. I have seen cases where other peripherals which use the HFXO are affected by the switching due to the Softdevice. In these cases I usually recommend starting the HFXO manually as in this case. Forcing HFXO to be ON will indeed consume a considerable higher current, which is why we suggest turning it OFF after the peripheral is done using it.

[quote user=""]Should we call sd_clock_hfclk_release() at the end of SPI activity, or might we be interrupting some other process that needs HFCLK?[/quote]

If you're only using the Softdevice then it's ok to just call sd_clock_hfclk_release(). If some parts of your application is already using the CLOCK driver then you should use that API instead.

regards

Jared