⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
10 posts / 0 new
Last post
托马斯唐豪瑟
Offline
Last seen:3个月3周前
加入:2019-10-20 10:45
Crash on hw_cpm_pll_sys_on()

Hi,

我有两个DA14683 USB开发套件。在我的system_init()函数中我打电话

cm_sys_clk_init(sysclk_PLL96); to speed up.

cm_sys_clk_init() calls in turn this code where in switch_to_pll().

if(cm_poll_xtal16m_ready()){switch_to_xtal16();if((type == sysclk_pll48)||(type == sysclk_pll96))){switch_to_pll();}}

在switch_to_pll() this code is invoked:

static void switch_to_pll(void) { if (hw_cpm_is_pll_locked() == 0) { hw_cpm_pll_sys_on(); // Turn on PLL } ... ...

现在有趣的是,在一个板上,函数hw_cpm_is_pll_locked()返回0和hw_cpm_pll_sys_on()被调用。在另一个板上,B未锁定PLL,并且未调用HW_CPM_PLL_SYS_ON()。

On crash the execution get stuck in

__retained_code void hw_watchdog_handle_int(无符号long *异常_args){... ... hw_cpm_assert_trigger_gpio();if(reg_getf(crg_top,sys_stat_reg,dbg_is_active)){get the这里----> __bkpt(0);}否则{虽然(1);} ...... ......}

最后,只有在使用调试器的代码上才会发生这种情况。

在开发OTP安全引导加载程序的代码时,我禁止此错误/问题

1)我想知道我可以对它做些什么吗?

2)为什么PLL在一个板上关闭而不是另一个电路板?

Thank you,

Thomas

设备:
PM_Dialog
Offline
Last seen:3天8小时前
工作人员
加入:2018-02-08 11:03
嗨托马斯唐豪斯,

嗨托马斯唐豪斯,

让我根据初始帖子使用DA14683,将“设备”选择从DA14580更改为DA1468x。

You mentioned that“最后,只有当我通过调试器逐步时,才会发生这种情况。”

Do you mean that you are stepping into the code while the debugger is attached?

Is that happening when running the application normally – without the debugger attached?

The debugger will mask out all the interrupts. So the application might be waiting to get the appropriate interrupt when the PLL is ready, which never arrives, as all the interrupts are masked out. The reason why this is happening in one board and in the other not, this is probably why the interrupt arrived earlier in the second case. Generally, when the debugger is attached, all the interrupts are disable in HW level. If you are stepping into the code, the best approach might be to add a breakpoint somewhere in your code and run it instead of stepping into the code.

However, please indicate if the problem exists or not when you are running the application without the debugger attached. Waiting your feedback on this. This issue is not related with Secure Boot functionality - probably the debugger causes this.

谢谢,PM_Dialog

托马斯唐豪瑟
Offline
Last seen:3个月3周前
加入:2019-10-20 10:45
你好pm_dialog,

你好pm_dialog,

Thank you for fast answer. I spent another sleepless night on this issue and I found out this:

1) To mitigate the error I callhw_cpm_pll_sys_off()beforeswitch_to_pll(sysclk_PLL48).

if (!hw_cpm_check_xtal16m_status()) { hw_cpm_enable_xtal16m(); while (!hw_cpm_is_xtal16m_trimmed()); } hw_cpm_set_sysclk(SYS_CLK_IS_XTAL16M); hw_cpm_set_hclk_div(0); hw_cpm_set_pclk_div(0); /* THIS IS TO AVOID THE ERROR */ hw_cpm_pll_sys_off(); /* Speedup booting time */ switch_to_pll(sysclk_PLL48); /* Enable OTP Controller */ hw_otpc_init(); ... ...

因此,从我的视点看起来它看起来寄存器未正确设置重新启动并调用hw_cpm_pll_sys_off()inalliges它。但我仍然没有为什么在一个板上是必要的,而不是另一个。这对我有用,但我觉得它不太舒服,只长时间我没有可行的解释。

2) The Problem occures not if debugging is not attached.

3) The problem occures on any programm, regardless of ROM or QSPI when debugging is attached. And it doen't matter where the first breakpoint is placed to.

谢谢!

Thomas

PM_Dialog
Offline
Last seen:3天8小时前
工作人员
加入:2018-02-08 11:03
嗨托马斯唐豪斯,

嗨托马斯唐豪斯,

Thanks for your suggestion – I will review it.

>>>The Problem occures not if debugging is not attached.

这意味着如果您通常在没有连接的调试器的情况下运行代码。它正在处理两种设备。我的理解是否正确?

>>> The problem occures on any programm, regardless of ROM or QSPI when debugging is attached. And it doesn’t matter where the first breakpoint is placed to.

As mentioned before, this is expected because when the debugger is attached, the interrupts are masked out.

谢谢,PM_Dialog

托马斯唐豪瑟
Offline
Last seen:3个月3周前
加入:2019-10-20 10:45
> > > >这意味着如果你

> > > >这意味着如果你run the code normally without the debugger attached. It is working on both devices. Is my understanding correct?

Yes, this is correct!

PM_Dialog
Offline
Last seen:3天8小时前
工作人员
加入:2018-02-08 11:03
托马斯唐豪瑟

托马斯唐豪瑟

预期此行为。如前所述,当调试器附加时,中断被屏蔽,因此这就是为什么PLL无法锁定。

谢谢,PM_Dialog

托马斯唐豪瑟
Offline
Last seen:3个月3周前
加入:2019-10-20 10:45
嗨pm_dialog,

嗨pm_dialog,

1) Your answer does not explain why it work on one board and not on the other.

2)如果您所说的是真的,那么它无法在48或96 MHz上调试。但事实上它是可能的。这将意味着无法调试访问需要48 MHz的OTP的程序。所以你认真吗?

3) Why does calling hw_cpm_pll_sys_off() solve the problem is also not answered by what you say.

So I ask you to think again an to give me more detailed answers.

Thank you regards,

Thomas

PM_Dialog
Offline
Last seen:3天8小时前
工作人员
加入:2018-02-08 11:03
嗨托马斯唐豪斯,

嗨托马斯唐豪斯,

对不起,但可能我没有正确地写作。是的,使用PLL运行时,您可以调试代码,但无法进入代码。我以为你正在进入代码。我再次读取了您的初始帖子,我看到您正在启动CLOW到PLL(CM_SYS_CLK_INIT(SYSCLK_PLL96))的时钟源)。你能给XTAL16M发起时钟,然后将其设置为PLL96吗?例如,在PXP_Reporter示例中,请使用以下配置:

cm_sys_clk_init(sysclk_xtal16m);cm_apb_set_clock_divider(apb_div1);cm_ahb_set_clock_divider(ahb_div1);cm_lp_clk_init();/* .......*/ / *设置系统时钟* / cm_sys_clk_set(sysclk_pll96);

Please try the aforementioned suggestion and let me know if this is working on both boards. When calling the hw_cpm_pll_sys_off() the PLL is disabled that’s why the issue does not exist.

谢谢,PM_Dialog

托马斯唐豪瑟
Offline
Last seen:3个月3周前
加入:2019-10-20 10:45
你好pm_dialog,

你好pm_dialog,

您的建议在两个董事会的预期工作。但这是OS_Freertos的Aproach。选择OS_BareMetal时发生的问题。我使用与ble_suota_loader相同的设置(请参阅main_secure.c的init()函数)。

我的修复与hw_cpm_pll_sys_off();在调用switch_to_pll48()之前提到的电路板是必要的。

This code works:

static void init(void) { if (!hw_cpm_check_xtal16m_status()) { hw_cpm_enable_xtal16m(); while (!hw_cpm_is_xtal16m_trimmed()); } hw_cpm_set_sysclk(SYS_CLK_IS_XTAL16M); hw_cpm_set_hclk_div(0); hw_cpm_set_pclk_div(0); /* Enable OTP Controller */ hw_otpc_init(); /* FIX THAT SOLVED THE PROBLEM OF CHRASHING IN hw_cpm_pll_sys_on() */ hw_cpm_pll_sys_off(); /* Speedup booting time */ switch_to_pll48(); hw_watchdog_freeze(); // stop watchdog hw_cpm_deactivate_pad_latches(); // enable pads hw_cpm_power_up_per_pd(); // exit peripheral power down }

如果没有修复,崩溃发生在循环中永远不会返回的循环中。

void hw_cpm_pll_sys_on(void){.... / *等到锁定。* / whist((gpreg-> pll_sys_status_reg&reg_msk(gpreg,pll_sys_status_reg,pll_lock_fine))== 0){}}

应用程序在hw_watchdog.c中陷入困境的代码:

__retataDed_code void hw_watchdog_handle_int(无符号长*异常_args){.... hw_cpm_aster_trigger_gpio();if(reg_getf(crg_top,sys_stat_reg,dbg_is_active)){__bkpt(0);// <---------------这里陷入困境} ...}

My problem with this error is that I do not have a clear answer why it happens on one board and why my fix solves the problem. So I'd very much appreciate a understandable answer.

Thank you,

Thomas

PM_Dialog
Offline
Last seen:3天8小时前
工作人员
加入:2018-02-08 11:03
嗨托马斯唐豪斯,

嗨托马斯唐豪斯,

Is this ticket related with this one?

https://support.dialog-semicondiondiondum./forums/post/dialog-smartbond-bluetooth-low-energy-%2%80%93-software/what-right-configuration-secure-boot.

如我之前的评论中所述,您应该将系统时钟初始化为XTAL16M,然后将其切换到PLL。原因是因为在切换到PLL之前应该稳定XTAL16M。PLL基于XTAL16M,因此XTAL16M应首先稳定,否则PLL将永远不会锁定。你起诉的sdk例子是什么?调用n hw_cpm_pll_sys_off()在调用此函数之前,必须将系统时钟设置为XTAL16M。因此,它可能与XTAL16M一起运行的系统。

谢谢,

PM_Dialog