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 ? 

Hello Hung,

Thanks for your responses.  I will try the XTAL setup you show below and let you know what I see today.  I am the hardware guy for us but know enough firmware to be 'dangerous' so there may be some things that are not obvious to me on the firmware side but I can get things configured the way I need them and verify they are operating in the modes I need via Spectrum Analyzers, Scopes, and Power measurement tools.

1) If the XTAL warm-up is 1.5ms then I am rather confused as to why the Errata for the nRF52810-QCAA CLOCK: EVENTS_HFCLKSTARTED can be generated before HFCLK is stable specifically mentions 400us as being the critical time value that the 32MHz XTAL must startup in or the Errata can cause issues?

2) Read Range & Connectable vs. Non-Connectable Configurations:  Yes I agree generally one would think that a BLE Scanner should always pick up a BLE Advertisement if it sees it BUT what I can tell you that there is a CLEAR DIFFERENCE between 'Read Ranges' with our hardware configured with the DC/DC converter with Connectable vs. Non-Connectable beacons.  I also agree that a major clue is that the Connectable Beacons all have a Scan-Response and my hunch is as you mention that if the BLE Scanner/Mobile App does not get the Scan Response then it assumes the BLE Beacon is not there and does not show it in the list of Beacons that it sees.

3) nrf_pwr_mgmnt_run() OK understand the net effect I can clearly see is that IF logging is disabled and this function is called I get my expected AVG IDD for a nRF52810 with a 2000ms ADV Interval which means it is going to SLEEP between ADV Tx's.  If I don't allow this function to be called the device never goes to sleep and the interesting thing is that IF the device DOES NOT GO TO SLEEP I get ~2X the Read Range of the Same hardware with the same software but is allowed to go to sleep...hence the Errata I have been referring to...

4) I have no problem sharing schematics and Gerbers but I will need to move this to a private case to do so...is there a way to transfer this to be a private case or should I enter a new private case...?

Regards,

Frank

Hello Hung,

Thanks for your responses.  I will try the XTAL setup you show below and let you know what I see today.  I am the hardware guy for us but know enough firmware to be 'dangerous' so there may be some things that are not obvious to me on the firmware side but I can get things configured the way I need them and verify they are operating in the modes I need via Spectrum Analyzers, Scopes, and Power measurement tools.

1) If the XTAL warm-up is 1.5ms then I am rather confused as to why the Errata for the nRF52810-QCAA CLOCK: EVENTS_HFCLKSTARTED can be generated before HFCLK is stable specifically mentions 400us as being the critical time value that the 32MHz XTAL must startup in or the Errata can cause issues?

2) Read Range & Connectable vs. Non-Connectable Configurations:  Yes I agree generally one would think that a BLE Scanner should always pick up a BLE Advertisement if it sees it BUT what I can tell you that there is a CLEAR DIFFERENCE between 'Read Ranges' with our hardware configured with the DC/DC converter with Connectable vs. Non-Connectable beacons.  I also agree that a major clue is that the Connectable Beacons all have a Scan-Response and my hunch is as you mention that if the BLE Scanner/Mobile App does not get the Scan Response then it assumes the BLE Beacon is not there and does not show it in the list of Beacons that it sees.

3) nrf_pwr_mgmnt_run() OK understand the net effect I can clearly see is that IF logging is disabled and this function is called I get my expected AVG IDD for a nRF52810 with a 2000ms ADV Interval which means it is going to SLEEP between ADV Tx's.  If I don't allow this function to be called the device never goes to sleep and the interesting thing is that IF the device DOES NOT GO TO SLEEP I get ~2X the Read Range of the Same hardware with the same software but is allowed to go to sleep...hence the Errata I have been referring to...

4) I have no problem sharing schematics and Gerbers but I will need to move this to a private case to do so...is there a way to transfer this to be a private case or should I enter a new private case...?

Regards,

Frank

Hi Franks, 

Thanks for the information. It's indeed quite strange issue that you have here. Especially with the test result about the code I suggested to run at the beginning of main() and the test result of the RF Spectrum. 

Ketil will handle the private case that you created as he has the most experience in radio and hardware among us in our team. I will work along side with him on this case. We will try to test on the hardware that you sending us.