你好，
I have two da14683 USB Development Kit. In my system_init() function I call
cm_sys_clk_init（sysclk_pll96.）;加快。
cm_sys_clk_init()调用这个代码switch_to_pll().
if (cm_poll_xtal16m_ready()) { switch_to_xtal16(); if ((type == sysclk_PLL48) || (type == sysclk_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} ......Now the funny thing ist that on one board A the function hw_cpm_is_pll_locked() return 0 and hw_cpm_pll_sys_on() is called. On the other board B the pll is not locked and the hw_cpm_pll_sys_on() not called.
在崩溃时，执行陷入困境
__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); } ... ... }And finally this happens only when I step thru the code with debugger.
I disvovered this error / problem while developing code for an OTP-Secure Bootloader and
1) I want to know what I can do against it?
2) Why is PLL turned off on one board and not the the other?
谢谢，
托马斯
Device:
Hi Thomas Donhauser,
Let me change the “Device” selection from DA14580 to DA1468x, as you are using DA14683 according to your initial post.
你提到了这一点“And finally this happens only when I step thru the code with debugger.”
您是否意味着在调试器附加时，您正在进入代码？
那是在运行申请时发生的 - 没有调试器所连接的吗？
调试器将屏蔽所有中断。因此，当PLL准备就绪时，应用程序可能正在等待获得适当的中断，从未到达，因为所有中断都被屏蔽。在一个板上发生这种情况的原因是，另一个不是，这可能是为什么中断在第二种情况下到达的原因。通常，当连接调试器时，所有中断都禁用HW级别。如果您正在进行代码，则最佳方法可能是在代码中的某处添加断点并运行它而不是踩到代码中。
但是，请指示问题是否存在，如果您在没有调试器的情况下运行应用程序时是否存在。等待您的反馈意见。此问题与安全启动功能无关 - 可能调试器会导致此功能。
谢谢，PM_DIALOG.
Hello PM_Dialog,
谢谢你的快速答案。我在这个问题上度过了另一个不眠之夜，我发现了这个问题：
1）减轻我呼叫的错误hw_cpm_pll_sys_off()前switch_to_pll（sysclk_pll48）。
So from my standpoint of view it looks like that the register is not properly setup on reboot and to call hw_cpm_pll_sys_off() initialises the it. But I still have no clue why this is necessary on one board and not on the other. This works for me, but I feel not very much comfortable with it as long long I don not have a feasible explanation.
2）如果未附加调试，则此问题不会发生。
3）问题发生在任何程序上，无论在调试时，无论ROM或QSPI如何。它在第一个断点放置到哪里有重要。
Thank you!
托马斯
Hi Thomas Donhauser,
谢谢你的建议 - 我会审查它。
>>>问题发生在未附加调试时不会发生。
This means that if you run the code normally without the debugger attached. It is working on both devices. Is my understanding correct?
>>>问题发生在任何程序上，无论在调试时，无论ROM或QSPI如何。并且它在第一个断点放置到哪里无关紧要。
如前所述，这是预期的，因为当调试器附加时，中断被屏蔽。
谢谢，PM_DIALOG.
>>>>这意味着如果您通常在没有连接的调试器的情况下运行代码。它正在处理两种设备。我的理解是否正确？
是的，这是正确的！
Hi Thomas Donhauser
This behavior is expected. As mentioned before, when the debugger is attached the interrupts are masked out so that’s why the PLL cannot lock.
谢谢，PM_DIALOG.
Hi PM_Dialog,
1）您的答案不会解释为什么它在一个板上工作而不是另一张。
2) If it is true what you say, then it is not possible to debug on 48 or 96 MHz. But in fact it is possible. This would mean that it is not possible to debug a programm that does access OTP which requires 48 Mhz. So are you serious?
3）为什么调用hw_cpm_pll_sys_off（）解决问题也没有得到你所说的。
所以我请你再次思考一个给我更详细的答案。
谢谢你，
托马斯
Hi Thomas Donhauser,
Sorry, but probably I didn’t write it correctly. Yes, you can debug your code when running with the PLL but you cannot step into the code. I thought that you were stepping into the code. I read again your initial post and I saw that you are initiating the clock source to the PLL (cm_sys_clk_init(sysclk_PLL96)). Can you please initiate the clock to the XTAL16M and then set it to PLL96? For example, in pxp_reporter example the SDK, please use the following configuration :
请尝试上述建议，并让我知道这是否在两个董事会上。调用hw_cpm_pll_sys_off（）禁用PLL，这就是为什么问题不存在的原因。
谢谢，PM_DIALOG.
Hello PM_Dialog,
your suggestion works as expected on both boards. But this is the aproach for OS_FREERTOS. The problem I mentioned occurs when OS_BAREMETAL is chosen. I used the same setup as in ble_suota_loader ( see the init() function in main_secure.c).
My fix is with hw_cpm_pll_sys_off(); is necessary on the board I mentioned before calling switch_to_pll48().
此代码有效：
Without the fix the crash happens in the last while-loop that never returns.
The code where the app get stuck in in hw_watchdog.c:
我这个错误的问题是我没有明确的答案，为什么它发生在一个板上，为什么我的修复解决问题。所以我非常欣赏一个可以理解的答案。
谢谢，
托马斯
Hi Thomas Donhauser,
这张票是与这个有关的吗？
https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bluetooth-low-energy-%E2%80%93-software/what-right-configuration-secure-boot
As mentioned in my previous comment, you should initialize the system clock to XTAL16M and then switch it to PLL. The reason is because the XTAL16M should be stabilized before switching to PLL. The PLL is based on XTAL16M, so the XTAL16M should be stabilized first, Otherwise the PLL will be never locked. What is the SDK example that you are suing? When calling the n hw_cpm_pll_sys_off() the system clock must have been set to XTAL16M before calling this function. So, the system it might runs with the XTAL16M.
Thanks,
PM_DIALOG.