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

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

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

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. 

Hello Hung,

  Read Range = Using Mobile Device in this case Android Galaxy Tab A with a BLE Client app such as nRF Connect.  These are connectable Beacons so I am simply measuring the distance at which the BLE Client during a SCAN picks up the Beacon Advertisement.  This is what we refer to as 'Read Range' the distance at which a BLE Client can reliably 'see' the Beacon Advertisement.  As simple as that.

• For 'Connectable Beacon' simple example would be BLE_Blinky as an example with DC/DC Enabled this 'Read Range' is basically 1/2 of the 'Read Range' for a Connectable Beacon with the LDO enabled.
• For a 'Non-Connectable Beacon' TX only I get the same read range whether the DC/DC is enabled or the LDO.  A simple example is the nRF Beacon example.
• For a 'Connectable Beacon' configured to use the DC/DC we can disable it from boing to SYSTEM OFF and we get the same Read Range as a LDO enabled 'Connectable Beacon' that utilizes SLEEP/SYSTEM OFF in between each Tx which is 2000ms.

When I mention Receiver Sensitivity I am referring to the nRF52810. 

We have done a new revision of the PCBA that was sent to Ketil in which we moved the 32MHz and 32kHz XTAL to the opposite side of the PCB from the nRF52810 to avoid possible 32MHz noise affecting the nRF52 Receive Sensitivity and increased the Cload cap values to 15pF for a 10pF Cload 32MHz XTAL.  We also re-arranged the DC/DC components slightly to match closer to the orientation of the nRF52810 Reference design.  The problem still exists.

We have also tested 'Shielded 10uH & 15nH' inductors thinking that possibly the switching noise is bleeding into the nRF52 RF Path/Receiver but yielded no noticeable improvement.

To avoid having the nRF52810 go to SYSTEM OFF we simply don't call the nrf_pwr_mgmt_run() so the nRF52810 never goes into a SLEEP Mode in between Beacon Transmits.

 Being that this is somehow tied to having the nRF52 wake from SYSTEM OFF/SLEEP mode I have also tried using the

sd_power_mode_set(NRF_POWER_MODE_CONSTLAT);

to see if that yielded any noticeable results.  Had no effect.

Last night I looked at the RF Spectrum from 2MHz - 2480MHz using the Radio Test app and put the nRF52 into Receiver Mode to inspect if there was a noticeable difference between when the DC/DC is enabled vs. LDO and you can see from the Spectrum plots there is no noticeable noise difference at the Receiver input between when the DC/DC is enabled vs. the LDO.

I am going to do the same thing but with using the simple ble_app_blinky example modified to have a longer Adv interval of 2000ms and with Logging disabled so it can enter SYSTEM OFF mode.

This comes back to the original topic of the Errata that talks about the EVENTS_HFCLKSTARTED that could be generated before the HFCLK is stable and if the XTAL stabilization time takes longer than 400us the Workaround indicates that the user MUST ADD A DELAY using a timer to ensure the XTAL has had enough time to stabilize.

At this time I don't have an easy way to probe or inspect the HFCLK.  It would have been nice to have the ability to output the HFCLK or a divided down version of it directly onto a GPIO Pin.  If there is an easy way to do this could you please instruct me how to do this.

Regards,

Frank

Hi Frank, 

If you have a look at this again: https://devzone.nordicsemi.com/power/w/opp/2/online-power-profiler-for-bluetooth-le

You can find that the softdevice will try to start the XTAL about 1.5ms before each advertising event or connection event. And by default after each connection/advertising event it will disable the XTAL to save power. 

This means that it is difficult for the application to intercept this procedure of the softdevice to extend the ramp up time (which is already quite long)  

However, there is one thing you can try to test is to start the XTAL before the softdevice started. In this case the softdevice will not turn off the XTAL after each connection/advertising event. 
Please add :

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

Before you call ble_stack_init();

This way we can be sure if the XTAL stabilization time is causing the issue. 

I'm not so clear about the Read Range on the phone. You mentioned that it's the range that the phone detect the beacon. However, I don't see why in your test connectable vs non-connectable could make any difference in the range test.

Since the phone should be able to detect the beacon regardless if the scan request/scan response is sent/received or not. What I meant is that if you do connectable beacon it should have the same range as non-connectable beacon if we don't take scan request /scan response into account. There is a chance that the phone discard the advertising packet if it doesn't receive scan response packet.

I would suggest to cross check by using one of our NRF52 DK as the scanner and perform the same test. 

Also one more thing to clarify, nrf_pwr_mgmt_run() will not put the device to SYSTEM OFF mode, instead it only put the device to  System ON idle mode (put the CPU to sleep). 

Could you please send us the schematic and PCB layout of your latest board ?