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,

  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 ? 

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 ?