Crystal trim and lld_sleep_compensate_func warning

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
9 posts / 0 new
Last post
mbwjr12
Offline
Last seen: 10 months 2 weeks ago
Joined: 2015-11-05 18:33
Crystal trim and lld_sleep_compensate_func warning

Dear Dialog,

After tuning the crystal on my latest batches of boards, I found that I was receiving ASSERT_WARNING in lld_sleep_compensate_func()

    // If this Assertion hits then the LP ISR lasts longer than the time
    // that has been reserved via LP_ISR_TIME_XTAL32_CYCLES and LP_ISR_TIME_USEC.
    if (sleep_lp_cycles && (sleep_lp_cycles < slp_period))
        ASSERT_WARNING(0);

My crystal trim is set to 0xFF, the maximum value / lowest frequency. The warning vanishes when I return the value to the default 0x80, but my BLE frequency error is greater at that point. My tuning process was to check the BLE frequency offset error with a spectrum analyzer and tune the crystal accordingly to minimize error.

Do you have any advice here? Is this a hardware design issue, should I investigate purchasing crystals with additional load capacitance, etc. ? I am using a 32MHz, 6pF crystal with +/-10ppm tolerance and aging (part no. XRCGB32M000F1H00R0).

Thanks,

Mike

Device: 
PM_Dialog
Offline
Last seen: 2 days 10 hours ago
Staff
Joined: 2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

Thanks for your question online and for your interest in our BLE solutions.

I would recommend first checking the AN-B-075: DA14531 Hardware Guidelines application note that provides the minimal reference schematic, circuit explanation, and design guidelines for BLE applications based on the DA14531 SoC.

Regarding the crystal oscillator specifications, please refer to section 3.2.2 and table Table 10.

Crystal trimming guidelines are described on section 3.2.2.1.

Thanks, PM_Dialog

mbwjr12
Offline
Last seen: 10 months 2 weeks ago
Joined: 2015-11-05 18:33
Hello Dialog,

Hello Dialog,

Yes, I referred to the crystal specs and hardware design guidelines in my design. I used the exact same crystal as the devkit. I have followed the layout guidelines and removed the planes underneath the crystal pads. In general, my design is as expected.

I have a few questions:

  • What is the mechanism causing this problem, is it because the 32MHz crystal takes longer than expected to start with the increased capacitance from setting the trim register to 0xFF?
  • What is the effect of this condition causing the warning? For example, if I were to use the PLT and it calibrated some of my crystals such that those boards experienced this, what effect would it have? Do I need to prevent this from happening in production?
  • Does Dialog Semi have recommendations about resolving this issue if the hardware design guidelines have been followed? For instance, should I try a 7pF crystal instead?
  • Is the source of the BLE frequency error solely determined by the accuracy of the crystal? If I had a theoretically perfect crystal at exactly 32MHz, would my frequency error be 0 or are there other sources of error in the system?

Thanks,

Mike

PM_Dialog
Offline
Last seen: 2 days 10 hours ago
Staff
Joined: 2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

Apologies for the delay. Let me check it and I’ll get back to you.

Thanks, PM_Dialog

PM_Dialog
Offline
Last seen: 2 days 10 hours ago
Staff
Joined: 2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

Regarding the specific warning, this means that the system spends too much time sleeping and is not able to wake up on time, so the SDK is warning you about this. Probably it might not be related to the crystal trimming, so I would like to check out.

This assertion can also occur if the DA14531 is active (no BLE core active) with the interrupts disabled and its time for BLE core to wake up. To do so, at some point when it’s time for the LP_Handler to execute since the interrupts are disabled the ISR delays execution (at some point the interrupts are enabled but the Handler isn't executed on time). With other words that means that the device was sleeping longer than the time defined and the ASSERTION will occur.

I am putting below some question in order to understand better the problem :

  1. Are you using the RCX or an external crystal oscillator as a Low Power Clock?
  2. Have you modified the BLE_WAKEUP_LP_Handler or any of the SDK files?
  3. Can please check if you manually disable the interrupts in any part of your code?
  4. Additionally, can you please check if you have a code snippet in the periph_init() that delays the system? The periph_init() will be executed in every wake up, so if you have code that delays the system, this will also delay the wake up.
  5. Are you using a custom code or any of the SDK example? Can this behavior be replicated with any of the SDK examples?

Thanks, PM_Dialog

mbwjr12
Offline
Last seen: 10 months 2 weeks ago
Joined: 2015-11-05 18:33
Hello,

Hello,

1. I am using RCX, no external LP crystal is used.

2. I have not. I have made two modifications to the SDK:

    1. to retrieve the BLE address easily I extern'd struct bd_addr app_random_addr

    2. I modified arch_system to retrieve the default crystal trim value from a config flag instead of the OTP if it isn't present, like this:

 #if defined (__DA14531__)
+#ifdef CFG_DEFAULT_XTAL32M_TRIM_VALUE^M
+#define DEFAULT_XTAL32M_TRIM_VALUE_QFN      (CFG_DEFAULT_XTAL32M_TRIM_VALUE)
+#define DEFAULT_XTAL32M_TRIM_VALUE_WLCSP    (CFG_DEFAULT_XTAL32M_TRIM_VALUE)
+#else

CFG_DEFAULT_XTAL32M_TRIM_VALUE is 0x80 for the QFN chip by default, which does not cause the warning, but at 0xFF it does.

3. I do not believe I ever disable interrupts. I have reviewed my code and have found no direct, or indirect through dialog API calls, way in which I disable them.

4. I have checked periph_init. The only calls it makes are to GPIO_ConfigurePin (lights_init() also just calls GPIO_ConfigurePin())

void set_pad_functions(void)        // set gpio port function mode
{
    GPIO_ConfigurePin(CLIP_SWITCH_PORT, CLIP_SWITCH_PIN, INPUT, PID_GPIO, false);
    GPIO_ConfigurePin(CLIP_TEMP_SENSOR_EN_PORT, CLIP_TEMP_SENSOR_EN_PIN, OUTPUT, PID_GPIO, false);
    GPIO_ConfigurePin(CLIP_TEMP_SENSOR_PORT, CLIP_TEMP_SENSOR_PIN, INPUT, PID_ADC, false);
}

void periph_init(void)  // set i2c, spi, uart, uart2 serial clks
{
#if defined (__DA14531__)
    // Disable HW Reset functionality of P0_0
    GPIO_Disable_HW_Reset();

    // In Boost mode enable the DCDC converter to supply VBAT_HIGH for the used GPIOs
    syscntl_dcdc_turn_on_in_boost(SYSCNTL_DCDC_LEVEL_3V0);
#else
    // Power up peripherals' power domain
    SetBits16(PMU_CTRL_REG, PERIPH_SLEEP, 0);
    while (!(GetWord16(SYS_STAT_REG) & PER_IS_UP));
    SetBits16(CLK_16M_REG, XTAL16_BIAS_SH_ENABLE, 1);
#endif

    // ROM patch
    patch_func();

    // Set pad functionality
    set_pad_functions();
    lights_init();

    // Enable the pads
    GPIO_set_pad_latch_en(true);
}

5. I am using custom code. The firmware is in a late beta or release candidate stage, it was only with the most recent batch of boards that this warning was experienced with the crystal tuning. I have not tried running sample code, if I have time I will investigate this.

 

If I cannot easily resolve this issue, it seems as long as my final tuning value keeps the initial frequency offset error within about 75KHz and without trimming the crystal too far to cause this warning, I should be fine in production. Max BLE error as per spec is 150KHz, and this should give me plenty of margin with a +/-10ppm initial, +/-10ppm temperature, and some aging tolerance on the crystal. If that's roughly 30ppm total worst case it's ~75KHz additional error possible at the expected lifespan of the product.

Thanks,

Mike

 

PM_Dialog
Offline
Last seen: 2 days 10 hours ago
Staff
Joined: 2018-02-08 11:03
Hi Mike,

Hi Mike,

  1. You could use download the Production Test firmware which is within the SDK (6.0.14.1114\projects\target_apps\prod_test\prod_test) and use the RF Master for the crystal trimming.

 

Please see section 24.1.4 from the user guide – link is provided below :

http://lpccs-docs.dialog-semiconductor.com/UM-B-083/tools/RfMaster.html

 

Then please use the Spectrum Analyzer so that you can decide which is the best trimming value.

 

After that, you can change the default value in the arch_system.c file. Please check DEFAULT_XTAL32M_TRIM_VALUE_QFN and DEFAULT_XTAL32M_TRIM_VALUE_WLCSP macro which hold the default trimming values.

 

  1. It would be great if you could run any of the SDK example in order to check if this can be replicated. Please it both with default and you own trimming value.

In the meanwhile I’ll check it again – as mentioned in my previous comment, the probable reason for this warning is because the system spends too much time sleeping and is not able to wake up on time.

Thanks, PM_Dialog

mbwjr12
Offline
Last seen: 10 months 2 weeks ago
Joined: 2015-11-05 18:33
I'm posting an update for

I'm posting an update for other people experiencing the same problem. I diagnosed it to a bad crystal: the latest production test batch was actually not using XRCGB32M000F1H00R0 like the earlier batches, and some alternative crystal was substituted with unknown characteristics.

Using a calibrated frequency counter, I was able to show that it was off by 52ppm at 25C, and likely worse at other temperatures. This exactly matched the error I was seeing with my spectrum analyzer (2.402GHz * 52ppm ~=125KHz error). It may also have had the wrong capacitance, etc. My issues were resolved when I soldered the correct part in its place.

So far, I have not been able to reproduce this issue with the correct crystal at the default trim of 0x80. I will update this thread if that changes, but otherwise I consider this issue closed.

 

PM_Dialog
Offline
Last seen: 2 days 10 hours ago
Staff
Joined: 2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

Thank you very much for your comment and for the indication. It will be very helpful for the community.

Thanks, PM_Dialog