nRF52810 Errata CLOCK: EVENTS_HFCLKSTARTED / How to Add Stabilization Time?

Hello Everyone,

  We are using a nRF52810. 

We have ran into an issue where our 32MHz XTAL can take longer than 400us and thus the Errata 3.6[68] CLOCK: EVENTS_HFCLKSTARTED can be generated before HFCLK is Stable has came into play and is affecting our Radio performance.

WORKAROUND:  States if the startup time can be longer than 400us the software must ensure using a timer that the 32MHz XTAL has had enough time to startup before using Peripherals such as the Radio/ADC/etc.

QUESTION:  While I see how to to manually start the Radio by the following lines of code...

      NRF_CLOCK->TASKS_HFCLKSTART = 1;
      while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0 );

How can I go about adding a constant delay before the Radio tries to use the HFCLK for the case that I get a HFCLKSTARTED = 1 but the XTAL truly hasn't stabilized?  I have tried adding delays but it has not seemed to work.  Can someone help me with having the ability to set a stabilization time that is longer than 400us that I can control. 

I have been using a simple project "ble_app_blinky" for this. 

Functionality I observe is that once the application enters the for(;;) loop and enters sleep and then wakes up the HFLCLK is not consistently stabilizing in time and dramatically affects our radio performance. 

Would be very grateful if someone can help me with being able to add an extra stabilization time inside the for(;;) loop that I can control the duration of the extra delay after the nRF52810 comes out of SLEEP and the HFXO is trying to stabilize before the Radio turns on.

I have attached the simple 'ble_app_blinky_mod' project I have been using.  You can place Unzip this directly into the examples/ble_peripheral folder and it will NOT overwrite the original 'ble_app_blinky' project as I have renamed the folder and project to 'ble_app_blink_mod'.

BTW - I am using SDK => nRF5_SDK_16.0.0_98a08e2 and S112 7.0.1

Thanks in Advance!!

Regards,

Frank

Parents
  • Hi Frank, 

    Could you clarify what you meant by "Read range" ? How did you test that ? Does it involve that the scan response need to be received on the phone to consider it as "readable" ? or only the initial advertising packet is enough ?


    When you mentioned " Receiver Sensitivity" , is it the RSSI on the phone or the RSSI on the device ?

    I noticed that you have a long discussion with our coworker Ketil on your other ticket, is this the same PCB as the one you sent to Ketil ? 

    Could you give more detail on how you avoid the device to enter SLEEP/SYSTEM OFF mode ? Please be noted that waking up from  System off will cause a chip reset. 

Reply
  • Hi Frank, 

    Could you clarify what you meant by "Read range" ? How did you test that ? Does it involve that the scan response need to be received on the phone to consider it as "readable" ? or only the initial advertising packet is enough ?


    When you mentioned " Receiver Sensitivity" , is it the RSSI on the phone or the RSSI on the device ?

    I noticed that you have a long discussion with our coworker Ketil on your other ticket, is this the same PCB as the one you sent to Ketil ? 

    Could you give more detail on how you avoid the device to enter SLEEP/SYSTEM OFF mode ? Please be noted that waking up from  System off will cause a chip reset. 

Children
No Data
Related