你好
我有两个da14683 USB开发工具包。在我调用的system_init()函数中
系统时钟初始化(系统时钟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(); / /输出} ｝在开关_到_pll（）中调用此代码：
静态无效开关_至_pll（无效）{如果（hw_cpm_为_pll_锁定（）==0）{hw_cpm_pll_系统开启（）；//开启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准备就绪时，应用程序可能正在等待获得适当的中断，而PLL永远不会到达，因为所有中断都被屏蔽了。为什么在一个电路板上发生这种情况而在另一个电路板上不发生这种情况，这可能就是为什么在第二种情况下中断提前到达的原因。通常，在连接调试器时，所有中断都在硬件级别禁用。如果要单步执行代码，最好的方法可能是在代码中的某个位置添加断点并运行它，而不是单步执行代码。
但是，在未连接调试器的情况下运行应用程序时，请指出问题是否存在。请等待您对此的反馈。此问题与安全引导功能无关-可能是调试器导致的。
谢谢，下午好
你好PM_Dialog,
谢谢你的快速回答。我在这个问题上又度过了一个不眠之夜，我发现：
1） 为了减轻错误，我调用hw_cpm_pll_sys_off ()之前切换到pll（系统时钟PLL48）.
因此，从我的观点来看，似乎寄存器在重新启动时没有正确设置，调用hw_cpm_pll_sys_off()会初始化它。但我还是不知道为什么在一块黑板上有这个必要，而在另一块上没有。这对我来说是可行的，但只要我没有一个可行的解释，我就会觉得不太舒服。
2） 如果未附加调试，则不会出现问题。
3） 当附加调试时，无论是ROM还是QSPI，该问题都会发生在任何程序上。第一个断点放在哪里并不重要。
谢谢你！
托马斯
你好托马斯•Donhauser
谢谢你的建议，我会重新考虑的。
>>>如果未附加调试，则不会出现问题。
这意味着如果你在没有附加调试器的情况下正常运行代码。它在两种设备上都能运行。我的理解正确吗?
>>>当附加调试时，无论是ROM还是QSPI，该问题都会发生在任何程序上。第一个断点放在哪里并不重要。
如前所述，这是预期的，因为当附加调试器时，中断被屏蔽。
谢谢，下午好
>>>>这意味着，如果您在没有附加调试程序的情况下正常运行代码。它在这两种设备上都起作用。我的理解正确吗？
是的，这是正确的！
你好托马斯Donhauser
这种行为是预期的。如前所述，当附加调试器时，中断被屏蔽掉，这就是为什么PLL不能锁定。
谢谢，下午好
嗨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,
你的建议在两个委员会中都如预期的那样有效。但这是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_对话框