水晶装饰和lld_sleep_compensate_func警告

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())

空白set_pad_functions(空白)/ /设置gpio端口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

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.