你好，
我有两个da14683 USB开发工具包。在我调用的system_init()函数中
cm_sys_clk_init（sysclk_pll96.）;加快。
cm_sys_clk_init（）依次调用此代码在switch_to_pll（）中。
If (cm_poll_xtal16m_ready()) {switch_to_xtal16();if ((type == syscclk_pll48) || (type == syscclk_pll96)) {switch_to_pll(); / /输出} ｝在switch_to_pll（）中调用此代码：
静态void switch_to_pll（void）{if（hw_cpm_is_pll_locked（）== 0）{hw_cpm_pll_sys_on（）;//打开pll} ......现在有趣的是，在一块板A上，函数hw_cpm_is_pll_locked()返回0，并调用hw_cpm_pll_sys_on()。在另一块板B上，锁未被锁定，hw_cpm_pll_sys_on()未被调用。
在崩溃时，执行陷入困境
__RETAINED_CODE void hw_watchdog_handle_int(unsigned long *exception_args) {... ...hw_cpm_assert_trigger_gpio ();if (REG_GETF(CRG_TOP, SYS_STAT_REG, DBG_IS_ACTIVE)) {Get stuck here ----> __BKPT(0);} else {while (1);}……｝最后，只有当我使用调试器逐步通过代码时，才会发生这种情况。
我发现这个错误/问题时，为一个otp安全引导加载程序开发代码和
我想知道我能做些什么来对抗它?
2)为什么锁相环在一块板上关闭而不是在另一块板上?
谢谢，
托马斯
设备:
你好托马斯•Donhauser
让我将“Device”选项从DA14580更改为DA1468x，因为根据您最初的帖子，您正在使用DA14683。
你提到了这一点“最后，只有当我使用调试器逐步调试代码时，才会发生这种情况。”
您是否意味着在调试器附加时，您正在进入代码？
那是在运行申请时发生的 - 没有调试器所连接的吗？
调试器将屏蔽所有中断。因此，当PLL准备就绪时，应用程序可能正在等待获得适当的中断，从未到达，因为所有中断都被屏蔽。在一个板上发生这种情况的原因是，另一个不是，这可能是为什么中断在第二种情况下到达的原因。通常，当连接调试器时，所有中断都禁用HW级别。如果您正在进行代码，则最佳方法可能是在代码中的某处添加断点并运行它而不是踩到代码中。
但是，请指示问题是否存在，如果您在没有调试器的情况下运行应用程序时是否存在。等待您的反馈意见。此问题与安全启动功能无关 - 可能调试器会导致此功能。
谢谢，PM_DIALOG.
你好PM_Dialog,
谢谢你的快速答案。我在这个问题上度过了另一个不眠之夜，我发现了这个问题：
1）减轻我呼叫的错误hw_cpm_pll_sys_off ()前switch_to_pll（sysclk_pll48）。
因此，从我的观点来看，似乎寄存器在重新启动时没有正确设置，调用hw_cpm_pll_sys_off()会初始化它。但我还是不知道为什么在一块黑板上有这个必要，而在另一块上没有。这对我来说是可行的，但只要我没有一个可行的解释，我就会觉得不太舒服。
2）如果未附加调试，则此问题不会发生。
3）问题发生在任何程序上，无论在调试时，无论ROM或QSPI如何。它在第一个断点放置到哪里有重要。
谢谢你！
托马斯
你好托马斯•Donhauser
谢谢你的建议 - 我会审查它。
>>>问题发生在未附加调试时不会发生。
这意味着如果你在没有附加调试器的情况下正常运行代码。它在两种设备上都能运行。我的理解是否正确？
>>>问题发生在任何程序上，无论在调试时，无论ROM或QSPI如何。并且它在第一个断点放置到哪里无关紧要。
如前所述，这是预期的，因为当调试器附加时，中断被屏蔽。
谢谢，PM_DIALOG.
>>>>这意味着如果您通常在没有连接的调试器的情况下运行代码。它在两种设备上都能运行。我的理解是否正确？
是的，这是正确的！
你好托马斯Donhauser
这种行为是预期的。如前所述，当附加调试器时，中断被屏蔽掉，这就是为什么PLL不能锁定。
谢谢，PM_DIALOG.
嗨PM_Dialog,
1）您的答案不会解释为什么它在一个板上工作而不是另一张。
2)如果你说的是真的，那么就不可能在48或96 MHz上调试。但事实上，这是可能的。这将意味着它不可能调试一个程序，这需要48mhz的OTP访问。你是认真的吗?
3）为什么调用hw_cpm_pll_sys_off（）解决问题也没有得到你所说的。
所以我请你再次思考一个给我更详细的答案。
谢谢你，
托马斯
你好托马斯•Donhauser
抱歉，可能我没写对。是的，当使用PLL运行时，您可以调试代码，但您不能进入代码。我以为你是在破解密码。我再次阅读了您最初的帖子，我看到您正在启动时钟源的PLL (cm_sys_clk_init(sysclk_PLL96))。你能将时钟初始化到XTAL16M，然后设置到PLL96吗?例如，以pxp_reporter为例的SDK，请使用以下配置:
请尝试上述建议，并让我知道这是否在两个董事会上。调用hw_cpm_pll_sys_off（）禁用PLL，这就是为什么问题不存在的原因。
谢谢，PM_DIALOG.
你好PM_Dialog,
你的建议在两个委员会中都如预期的那样有效。但这是OS_FREERTOS的方法。我提到的问题是在选择OS_BAREMETAL时出现的。我使用了与ble_suota_loader相同的设置(参见main_secure.c中的init()函数)。
我的修复是使用hw_cpm_pll_sys_off();在我之前提到的调用switch_to_pll48()的板上是必要的。
此代码有效：
如果没有修复，崩溃将在最后一个while循环中发生，并且永远不会返回。
在hw_watchdog.c中应用程序卡住的代码:
我这个错误的问题是我没有明确的答案，为什么它发生在一个板上，为什么我的修复解决问题。所以我非常欣赏一个可以理解的答案。
谢谢，
托马斯
你好托马斯•Donhauser
这张票是与这个有关的吗？
https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bluetooth-low-energy-%E2%80%93-software/what-right-configuration-secure-boot
正如我在前面的评论中提到的，您应该将系统时钟初始化为XTAL16M，然后将它切换到PLL。原因是XTAL16M在切换到锁相环之前应该是稳定的。PLL是基于XTAL16M，所以XTAL16M应该首先是稳定的，否则PLL将永远不会被锁定。你起诉的SDK例子是什么?当调用n个hw_cpm_pll_sys_off()时，在调用这个函数之前，系统时钟必须被设置为XTAL16M。所以，系统可能和XTAL16M一起运行。
谢谢,
PM_DIALOG.