你好,
我有两个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()中调用以下代码:
Static 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