水晶装饰和lld_sleep_compensate_func警告

⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
9 posts / 0 new
最后一篇
mbwjr12
离线
最后一次露面:1 month 1 week ago
加入:2015-11-05 18:33
水晶装饰和lld_sleep_compensate_func警告

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
//已通过LP_ISR_TIME_XTAL32_CYCLES和LP_ISR_TIME_USEC保留。
if(sleep_lp_cycles &&(sleep_lp_cycles 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,

麦克风

Device:
PM_Dialog
离线
最后一次露面:2days 5 hours ago
职员
加入:2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

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

我建议首先检查AN-B-075: DA14531 Hardware Guidelines应用笔记,提供了基于DA14531 SOC的最小参考原理图,电路解释和设计指南。雷竞技安卓下载

关于晶体振荡器规格,请参阅第3.2.2节和表10。

Crystal trimming guidelines are described on section 3.2.2.1.

谢谢,PM_DIALOG.

mbwjr12
离线
最后一次露面:1 month 1 week ago
加入:2015-11-05 18:33
你好对话框,

你好对话框,

是的,我在设计中提到了Crystal Specs和硬件设计指南。我用完全相同的水晶作为devkit。我遵循了布局指南,并从水晶垫下方移除了平面。一般来说,我的设计正如预期的那样。

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?
  • 如果遵循硬件设计指南,对话框半是否有关于解决此问题的建议?例如,我应该尝试7PF水晶吗?
  • 是BLE频率误差的源极,仅通过晶体的准确性决定?如果我在32MHz的理论上有一个理论上完美的水晶,我的频率误差是否为0,或者系统中有其他错误源吗?

Thanks,

麦克风

PM_Dialog
离线
最后一次露面:2days 5 hours ago
职员
加入:2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

为延迟道歉。让我检查一下,我会回复你。

谢谢,PM_DIALOG.

PM_Dialog
离线
最后一次露面:2days 5 hours ago
职员
加入:2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

关于具体警告,这意味着系统花费太多时间睡眠,无法按时醒来,因此SDK警告您。可能它可能与水晶修剪有关,所以我想退房。

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.

我在一些问题下面才能理解更好的问题:

  1. 您是否使用RCX或外部晶体振荡器作为低功耗时钟?
  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?

谢谢,PM_DIALOG.

mbwjr12
离线
最后一次露面:1 month 1 week ago
加入:2015-11-05 18:33
你好,

你好,

1.我使用RCX,没有使用外部LP晶体。

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.如果不存在,我修改了Arch_System以从Config标志而不是OTP检索默认的Cryst Carrim值,如下所示:

#if定义(__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); }

我正在使用自定义代码。固件处于延迟测试版或发布候选阶段,只有最近的批次批次,即晶体调整经历了此警告。如果我有时间,我还没有尝试运行示例代码我会调查这个问题。

如果我不能轻易解决这个问题,似乎只要我的最终调谐值保持在大约75kHz内的初始频率偏移误差,而无需修剪晶体即可导致此警告即可,我应该良好的生产。MAX BLE错误按照规格为150kHz,这应该给我充足的余量,+/- 10ppm初始,+/- 10ppm温度,以及晶体上的一些老化容差。如果这是大约30ppm的总数最坏情况,则可以在产品的预期寿命中获得〜75khz的额外误差。

Thanks,

麦克风

PM_Dialog
离线
最后一次露面:2days 5 hours ago
职员
加入:2018-02-08 11:03
Hi Mike,

Hi Mike,

  1. 您可以使用下载SDK内的生产测试固件(6.0.14.1114 \ Projects \ target_apps \ prod_test \ prod_test),并使用RF主机进行水晶修剪。

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

然后请使用Spectrum Analyzer,以便您可以决定哪个是最佳修剪值。

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. 如果您可以运行任何SDK示例,则会很好,以检查是否可以复制此项。请默认情况下,您拥有修剪值。

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.

谢谢,PM_DIALOG.

mbwjr12
离线
最后一次露面:1 month 1 week ago
加入: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.

到目前为止,我无法在0x80的默认修剪中使用正确的水晶来重现此问题。如果该更改,我会更新此线程,但否则我认为此问题已关闭。

PM_Dialog
离线
最后一次露面:2days 5 hours ago
职员
加入:2018-02-08 11:03
Hi mbwjr12,

Hi mbwjr12,

非常感谢您的评论和指示。对社区非常有帮助。

谢谢,PM_DIALOG.