• State Not Answered
  • Replies 7 replies
  • Subscribers 25 subscribers
  • Views 260 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 290115
Options

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

user99394

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
  • 0

    Hi Frank, 

    Could you let me know which exact the radio performance issue you have ? 
    What's the worst start up time of your crystal ? 

    In the code that you provided I don't see how HFCLK_Delay(1000) can return 0. 

    And what you are trying to do by putting NRF_CLOCK->TASKS_HFCLKSTART = 1; in to the main loop ? Could you instead call this function at the beginning of main() instead ? 

    Note that the softdevice will start the HFCLK automatically about 1.5ms before it's actually using the HFCLK for the radio. 
    See here: https://devzone.nordicsemi.com/power/w/opp/2/online-power-profiler-for-bluetooth-le

  • 0 in reply to Hung Bui

    Hello Hung

      Yeah sorry I should have deleted the lines in the for(;;) loop I had been experimenting and was assuming that the HFXO could be started each time from the System OFF mode.  I will outline my issues with Radio performance but first to clarify there is still a possibility of the 32MHz XTAL not being stabilized before the EVENTS_HFCLKSTARTED is set to 1, correct? 

    ISSUE Observed:  This has been a long standing issue that must be solved to reduce IDD.  When the DC/DC is enabled we lose about 1/2 of the Read Range of our beacon.  Our beacon is a connectable beacon and thus must have a Scan Response.  We have tested the same hardware with LDO enabled and we get effectively 2X the Read range from a BLE Scanner looking for the Advertisements.  As soon as we enabled the DC/DC our Read Range from a BLE Client/Scanner is 1/2 the read range. 

    Testing: 

    1) I have performed testing with a TX Only Beacon with the DC/DC enabled and the same BLE Client/Scanner nRF Connect on Android in this case can see the Beacon at the same range as the same hardware enabled as a 'Connectable Beacon' with the LDO enabled.

    2)  I have tested the same hardware configured in a 'Connectable Beacon' mode ble_blinky app using the DC/DC BUT with not allowing the nRF52 to go to SLEEP and I also get the same Beacon Read Range from a BLE Client/Scanner as the hardware configured to use the LDO.

    Conclusions:  Based on the 2 tests above and other similar testing performed there MUST be an issue with one or both of the following scenarios...

    1) DC/DC Enabled is affecting Receiver Sensitivity in a significant fashion.  Otherwise the TX Only Beacon Mode would have same reduced BLE Client/Scanner Read Range.

    2) SYSTEM OFF has a direct affect on making this issue prevalent.  There is something going on with coming out of SYSTEM OFF every 2000ms and then turning on the Radio that is causing an issue.  If this was not the case then units that were not configured to utilize the SYSTEM OFF would have no noticeable difference to the same hardware that is programmed to go into SYSTEM OFF/SLEEP mode in between Advertising Transmits which is configured for ever 2000ms.

    We have been dealing with this issue for a long time now and have tested a couple different versions of PCBA's with slightly different Cload values and different Cl cap values on the 32MHz XTALs and we always seem to end up in the same spot which is when we enable the DC/DC converter we end up with 1/2 the Read range as the same hardware with the LDO configured.

    One could easily think that it is a 32MHz clock issue that is causing the Rx sensitivity degradation but this should also occur in the LDO mode if this was the case, correct?  Secondarily the fact that we get the same 'Read Range' or ability to see the Beacon Advertisements from a BLE Client(nRF Connect) from a unit configured to use the DC/DC that is NOT allowed to go to SLEEP/SYSTEM OFF mode seems to lend itself to an issue with getting the system to stabilize correctly after waking from SLEEP.  Hence the original assertion that this could be due to the Errata 3.6 [68] CLOCK: EVENTS_HFCLKSTARTED can be generated before HFCLK is stable. 

    My hunch is that once the DC/DC is enabled there is enough 4MHz switching noise that it is either causing the 32MHz XTAL longer than 400us to stabilize which brings into affect the Errata OR the 4MHz switching noise is impacting the Receive sensitivity.

    The culprit must lie in either the DC/DC switching noise reducing the Rx Sensitivity or once the 'COMING OUT OF SLEEP' with the DC/DC enabled is causing the XTAL longer than 400us to stabilize.

    Regards,

    Frank

Reply
  • 0 in reply to Hung Bui

    Hello Hung

      Yeah sorry I should have deleted the lines in the for(;;) loop I had been experimenting and was assuming that the HFXO could be started each time from the System OFF mode.  I will outline my issues with Radio performance but first to clarify there is still a possibility of the 32MHz XTAL not being stabilized before the EVENTS_HFCLKSTARTED is set to 1, correct? 

    ISSUE Observed:  This has been a long standing issue that must be solved to reduce IDD.  When the DC/DC is enabled we lose about 1/2 of the Read Range of our beacon.  Our beacon is a connectable beacon and thus must have a Scan Response.  We have tested the same hardware with LDO enabled and we get effectively 2X the Read range from a BLE Scanner looking for the Advertisements.  As soon as we enabled the DC/DC our Read Range from a BLE Client/Scanner is 1/2 the read range. 

    Testing: 

    1) I have performed testing with a TX Only Beacon with the DC/DC enabled and the same BLE Client/Scanner nRF Connect on Android in this case can see the Beacon at the same range as the same hardware enabled as a 'Connectable Beacon' with the LDO enabled.

    2)  I have tested the same hardware configured in a 'Connectable Beacon' mode ble_blinky app using the DC/DC BUT with not allowing the nRF52 to go to SLEEP and I also get the same Beacon Read Range from a BLE Client/Scanner as the hardware configured to use the LDO.

    Conclusions:  Based on the 2 tests above and other similar testing performed there MUST be an issue with one or both of the following scenarios...

    1) DC/DC Enabled is affecting Receiver Sensitivity in a significant fashion.  Otherwise the TX Only Beacon Mode would have same reduced BLE Client/Scanner Read Range.

    2) SYSTEM OFF has a direct affect on making this issue prevalent.  There is something going on with coming out of SYSTEM OFF every 2000ms and then turning on the Radio that is causing an issue.  If this was not the case then units that were not configured to utilize the SYSTEM OFF would have no noticeable difference to the same hardware that is programmed to go into SYSTEM OFF/SLEEP mode in between Advertising Transmits which is configured for ever 2000ms.

    We have been dealing with this issue for a long time now and have tested a couple different versions of PCBA's with slightly different Cload values and different Cl cap values on the 32MHz XTALs and we always seem to end up in the same spot which is when we enable the DC/DC converter we end up with 1/2 the Read range as the same hardware with the LDO configured.

    One could easily think that it is a 32MHz clock issue that is causing the Rx sensitivity degradation but this should also occur in the LDO mode if this was the case, correct?  Secondarily the fact that we get the same 'Read Range' or ability to see the Beacon Advertisements from a BLE Client(nRF Connect) from a unit configured to use the DC/DC that is NOT allowed to go to SLEEP/SYSTEM OFF mode seems to lend itself to an issue with getting the system to stabilize correctly after waking from SLEEP.  Hence the original assertion that this could be due to the Errata 3.6 [68] CLOCK: EVENTS_HFCLKSTARTED can be generated before HFCLK is stable. 

    My hunch is that once the DC/DC is enabled there is enough 4MHz switching noise that it is either causing the 32MHz XTAL longer than 400us to stabilize which brings into affect the Errata OR the 4MHz switching noise is impacting the Receive sensitivity.

    The culprit must lie in either the DC/DC switching noise reducing the Rx Sensitivity or once the 'COMING OUT OF SLEEP' with the DC/DC enabled is causing the XTAL longer than 400us to stabilize.

    Regards,

    Frank

Children
No Data
Related
Terms of service