SAME70 'PLL not locked' problem

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 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

  • 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

  • 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.

  • 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