Configuring SAMD21 for 48MHz

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


This question is distressingly familiar, but even after re-reading https://community.atmel.com/foru... carefully, I'm still stuck...

 

Short form:

 

I'm trying to configure SAMD21 Xplained Pro to run at 48Mhz via:

 

XOSC32K (32KHz) => GCLK3 (32KHz) => DFLL48M (47.972MHz) => GCLK0 (47.972) => CPU

 

It is hanging inside hri_gclk_wait_for_sync() while configuring GCLK3.

 

Details:

 

I'm using Atmel START with the following settings on the CLOCKs screen:

 

(In the following list, mentioning the setting means "enabled" and not mentioning means "disabled", except as noted otherwise):

 

XOSC32K:

External 32K Oscillator Enable

Run In Standby

Enable 32KHz output

Enable XTAL (tried both enabled and disabled -- no change)

Automatic Amplitude Control Enable: DISABLED (as per errata)

Start up time for the 32K Oscillator: 62592 us

 

GCLK3:

Run in Standby

Output Enable

Generic Clock Generator Enable

Generic clock generator 3 source: 32Khz External Crystal Oscillator (XOSC32K)

Generic clock generator 3 division: 1

 

DFLL48M:

Reference Clock Source: Generic clock generator 3

DFLL Enable

On Demand (also tried disabling, no change)

Operating Mode Selection: Closed Loop Mode

DFLL Multiple factor: 1464 (thank you, Lars...)

 

GCLK0:

Output Enable

Generic Clock Generator Enable

Generic clock generator 0 source: Digital Frequency Locked Loop (DFLL48M)

Generic clock generator 0 division: 1

 

Other stuff:

NVM Wait States: 1 (also tried 3 wait states, no change)

 

The Ask:

Any idea what I'm missing?  Would any of the config files be useful?

 

This topic has a solution.

- rdp

 

Last Edited: Thu. Sep 30, 2021 - 01:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Small update:

 

I reconfigured the system to use the 32KHz High Accuracy Internal Oscillator (OSC32K) and the system comes up normally. 

 

The SAMD21 Xplained Pro board includes a 32KHz external oscillator, so I'm not sure why using the XOSC32K would cause problems, but it certainly narrows down the places to look for trouble.

- rdp

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay - figured it all out.  What happened was I was making one change at a time, which masked the fact that there were two problems.

 

The winning recipe is to use the settings as shown above, with the following edits:

 

XOSC32K:

Enable XTAL: Enabled

 

Other stuff:

NVM Wait States: 1

(Boring details: When Enable XTAL didn't make a difference, I disabled it.  Subsequently I increased the wait states from 0 to 1, which was necessary, but I didn't re-enable Enable XTAL).

 

- rdp

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fearless_fool wrote:
Other stuff:

NVM Wait States: 1 

That's a frequent gotcha!  (been there, done that).

 

You'd have thought that a tool like START would, at the very least, warn you about that?

 

Perhaps you could raise a ticket about it ... ?

 

#NVMWaitStates #FlashWaitStates

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...