SAME70 'PLL not locked' problem

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
regjoe
regjoe's picture
Level: Hangaround
Joined: Fri. Jul 22, 2016
Posts: 174 View posts
Location: Aalen
#1
Posted by regjoe: Tue. Jan 9, 2018 - 04:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a custom board with an external 12MHz oscillator and the HW around it is similar to the E70 XPLD demo board. Therefore I am using the SAME70XPLD standard clock initialization in the ASF demo for the custom board.

 

Nevertheless, occasionally (ca. 1 of 100 times on ca. 20 boards) the board fails to boot and in the debugger I can see that the program hangs in the while() loop waiting for the PLL getting ready:

void pmc_mck_set_division(uint32_t ul_div)
{
    :
    PMC->PMC_MCKR =
			(PMC->PMC_MCKR & (~PMC_MCKR_MDIV_Msk)) | ul_div;
	while (!(PMC->PMC_SR & PMC_SR_MCKRDY));
}

In most cases I cannot even step thru the code, seems the Atmel Studio/debugger/CPU is frozen.

 

Any idea what can cause such a problem and how to handle/recover from such a situation ?

 

If the PLL is not running: can this cause to freeze in the debugging ? If so then an additional timeout check in the code above does not make much sense here ?

 

Even if this test is successful : is it possible that the PLL "unlocks" later ? Is there kind of 'fallback' to internal RC clock if PLL clock get out of order ?

 

What about using the watchdog instead ? Does the watchdog work if the PLL doesn't work ?

 

Is it possible to check the PLL signal on external pins and if so how to configure that ?

 

Although this problem might be hardware related: I want to increase the stability of the board in EMR polluted environment.

What about brown-out and clock failure detection ? Any hints / experience ?

 

Thanks,

Jochen

SAME newbie

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Top
regjoe
regjoe's picture
Level: Hangaround
Joined: Fri. Jul 22, 2016
Posts: 174 View posts
Location: Aalen
Posted by regjoe: Fri. Jan 12, 2018 - 11:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I found at least one problem in the clock initialization stuff of ASF.

 

If the clock initialization is done a second time then the CPU hangs up in the PLL re-configuration. In my case I do the clock initialization twice: in the boot loader and then in the application.

 

The same problem happens if I run the application in the debugger a second time. The first time after power-on the clock initialization is successful. But if I debug the application a second time then it sometimes hangs up in the PLL re-init, especially if I step thru the following code:

		pmc_disable_pllack(); // Always stop PLL first!
		PMC->CKGR_PLLAR = CKGR_PLLAR_ONE | p_cfg->ctrl;

I guess the reason is that after first clock init the core is fed by the PLL clock and stopping the PLL stops clocking the core.

 

There are two possible workarounds:

- skipping clock re-init if the clock is already initialized (requires checking clock config registers)

- re-config clock to internal RC clock and continue standard clock initialization

 

SAME newbie

Top
seni
seni's picture
Level: New Member
Joined: Thu. Sep 15, 2016
Posts: 4 View posts
Posted by seni: Fri. Oct 26, 2018 - 02:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ran into a similar issue during about 50-200 reboots of the same70 development board.

The code gets stuck while waiting for PLLA to lock in

 

uint32_t pmc_is_locked_pllack (void)
{
    return (PMC->PMC_SR & PMC_SR_LOCKA);
}

 

It always gets stuck during the 2nd initialization in the application (bootloader does the first).

Setting the main clock back to be run from the slow clock and disabling PLLA before reinitializing seems fixes the issue as described in the previous post.

Top
jerryr
jerryr's picture
Level: Hangaround
Joined: Fri. Apr 23, 2004
Posts: 374 View posts
Location: Liederbach; Germany
Posted by jerryr: Fri. Oct 26, 2018 - 06:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On a SAMD21J I used the big hammer method by setting the watchdog to reset the processor if the PLL didn't start within about 1/4 sec. This method isn't very useful if you're starting your application from a bootloader

Jerry

Top