• State Verified Answer
  • Replies 2 replies
  • Subscribers 86 subscribers
  • Views 282 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 353147
Options

HFXO Control for QSPI (Errata 244) - S140 v7.2.0 Integration & API Usage

MicroControl

Hi everyone,

I'm working with the nRF52840 using the nRF5 SDK v17.1.0 and SoftDevice S140 v7.2.0. My application uses QSPI for external Flash communication.

I have some doubts regarding the implementation of the workaround for the hardware anomaly Errata 244: "External flash and QSPI returns erroneous data when the SoftDevice is running."

1. SoftDevice Errata Fix Confirmation
My understanding, based on the errata documentation, is that Errata 244 is caused by a conflict when the HF clock switches (HFXO <-> HFINT) during QSPI operations. The workaround is implemented by ensuring HFXO stability.

Could you please definitively confirm that the fix for Errata 244 has been fully and correctly implemented in SoftDevice S140 since version 7.0.1 (or earlier, like v6.1.1)?
This confirmation would determine if we need to remove the manual application-level workaround.

2. Manual Workaroud Best Practice (if Needed)
Hypothetically, if the SoftDevice fix was not present, and we had to implement the workaround manually (e.g., using nrf_drv_clock_hfclk_request()):

  • Should we call nrf_drv_clock_hfclk_request() before every single QSPI read/write operation, and then immediately release the clock with nrf_drv_clock_hfclk_release()?

  • Or is it sufficient to call nrf_drv_clock_hfclk_request() once during QSPI initialization, and keep HFXO requested for the entire time the QSPI peripheral is active?

Thank you in advance for clarifying the official status and the recommended manual practice.

Parents
  • +1

    Hi MicroControl,

    The fix is not implemented in the softdevice as the softdevice doesn't have the code to check if there is a QSPI activity going on. 
    So you need to implement the HFXO request in the application code. 
    This approach is the correct one: 

    Should we call nrf_drv_clock_hfclk_request() before every single QSPI read/write operation, and then immediately release the clock with nrf_drv_clock_hfclk_release()?

    Keeping the HFXO running will draw more current so it's better to turn the request off when you finish with QSPI. Unless you have QSPI activity constantly making it more efficient to keep the HFXO on all the time, then you can just turn it on without turning it off. 

Reply
  • +1

    Hi MicroControl,

    The fix is not implemented in the softdevice as the softdevice doesn't have the code to check if there is a QSPI activity going on. 
    So you need to implement the HFXO request in the application code. 
    This approach is the correct one: 

    Should we call nrf_drv_clock_hfclk_request() before every single QSPI read/write operation, and then immediately release the clock with nrf_drv_clock_hfclk_release()?

    Keeping the HFXO running will draw more current so it's better to turn the request off when you finish with QSPI. Unless you have QSPI activity constantly making it more efficient to keep the HFXO on all the time, then you can just turn it on without turning it off. 

Children
Related
Terms of service