nRF52840 SPIM3, HFCLK, and anomaly 244

[Sydney]

We're working on a board with an nRF52840 running BLE with softdevice S140 and SDK 17. The board has an external SPI flash, and when we realized that SPIM3 can be run at higher speeds than the other SPIM instances, we thought we'd use that to speed up all of our transfers. But we immediately noticed lots of intermittent bit errors when reading or writing our external SPI flash on SPIM3 at 32MHz. There were also errors at 16MHz, but they generally seemed to be less. We looked at the signal and it didn't seem to be an obvious signal integrity issue, and after lots of testing it really seemed to be a timing issue, and we tracked it down to being an issue when BLE was actively in use (such as when scanning for advertisements).

Then I happened to check the errata, and I noticed anomaly 244. "QSPI: External flash and QSPI returns erroneous data when the SoftDevice is running."

https://infocenter.nordicsemi.com/topic/errata_nRF52840_Rev2/ERR/nRF52840/Rev2/latest/anomaly_840_244.html#anomaly_840_244

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.

• Is it expected that this anomaly would apply to SPIM3 in single SPI mode and not just QSPI?
• Does this workaround sound like the right approach?
• Are there any drawbacks to using this workaround? Is power consumption higher when HFCLK is running on HFXO?
• Should we call sd_clock_hfclk_release() at the end of SPI activity, or might we be interrupting some other process that needs HFCLK? (Do we need to manually coordinate HFCLK status with the rest of our application to make sure nothing else needs it before we turn it off?)

Thanks.

[Jared]

Hi there!

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.

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.

Should we call sd_clock_hfclk_release() at the end of SPI activity, or might we be interrupting some other process that needs HFCLK?

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