Unable to get ATSAMD10C13 to run at 48Mhz with internal oscillator using start / ASFv4

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

I'm trying to get a ATSAMD10C13 to run at 48mhz using the internal oscillator. I'm using Atmel Start to create the project.

 

As a test to see if the CPU is executing, I'm using the LED Flasher test program. With the default 1Mhz clock config the LED blinks. If I change the prescaler there to get to 8Mhz it also works. If I change the clock config to use OSC32K -> Clock 3 -> DFLL48M -> Clock 1 -> CPU and set NVM Wait States accordingly as specified in the datasheet, atmel start, various posts on this forum and every article I can find on the internet, it does not. The CPU appears to just be halted.

 

I have manually and automatically diffed my config and code against every snippet of code I could find to see if I'm missing something. I have read pretty deep into that datasheet. Made sure I have 4.7uF and 100nF decoupling capacitors. Checked to make sure that I am definitely running on 3.3V and a lot of other things. This has occupied me much of the weekend. I'm fresh out of ideas.

 

I uploaded screenshots of all the relevant screens in atmel start for both the working 8Mhz and not working 48Mhz configs. This is a fresh new project created with atmel start with no other changes made other than the one line change to the makefile to get it to compile on macs (Atmel/Microchip really should make that quick fix..) and copy/pasting the blink code into main.c.

 

My working and non-working .atstart files plus main.c is in this gist here: https://gist.github.com/lerouxb/...

 

I must be missing something, but I'm at the point where I'm starting to suspect a bug in atmel start even though I'm sure I would be super unlikely to be the first person to notice something like that or a defective chip or a chip with missing (or erased?) clock calibration settings in NVM..

 

Please help. I'm tearing out what little hair I have left.

Attachment(s): 

This topic has a solution.
Last Edited: Mon. Feb 22, 2021 - 11:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lerouxb wrote:
The CPU appears to just be halted

So have you used the debugger to find out what is actually happening?

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry I forgot to mention in the initial post. I'm not terribly good with gdb yet, but it appears to be stuck in:

 

hri_sysctrl_get_PCLKSR_OSC32KRDY_bit (hw=0x40000800) at ../hri/hri_sysctrl_d10.h:793
793		return (((Sysctrl *)hw)->PCLKSR.reg & SYSCTRL_PCLKSR_OSC32KRDY) >> SYSCTRL_PCLKSR_OSC32KRDY_Pos;

used in hpl/sysctrl/hpl_sysctrl.c:

 

#if CONF_OSC32K_CONFIG == 1
#if CONF_OSC32K_ENABLE == 1
	while (!hri_sysctrl_get_PCLKSR_OSC32KRDY_bit(hw))
		;
#endif
#if CONF_OSC32K_ONDEMAND == 1
	hri_sysctrl_set_OSC32K_ONDEMAND_bit(hw);
#endif
#endif

I don't really know what else to look for. Presumably it executed all the code up to that point? This is _sysctrl_init_sources() called by _init_chip() called by init_mcu() which is the first line in system_init() in driver_init.c. First line in atmel_start_init() called in my main().

 

Something in there I can dump to get an idea of what's going on? I guess I just assumed that atmel start would generate working code and that I configured the minimum required for it to work.

 

Is there a "run at 48Mhz with internal oscillator" example somewhere? Seems like it would be a common configuration.

 

I'll dig around more in the debugger and learn how to use it properly.

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

When I download a zip from https://gist.github.com/lerouxb/... I get two astart files but they are identical.

/Lars

 

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

Oops. Copy/paste error when I first created the gist. Both contained the 8Mhz config. I updated it now.

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

What's interesting is I just tried using the 8Mhz internal oscillator, divide that down by 250 in Clock generator 3 to get 32000, use that as the source for DFLL48M where it gets multiplied by 1500 to get 48Mhz and that works.

 

So I'm unblocked at the moment, but would really love to know why the previous method didn't work.

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

The 32KHz output needs to be enabled in the OSC32K settings.

/Lars

 

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

Oof. Thanks!

 

I'm now wondering in which cases you would enable the OSC32K but not the output? And why there's that asymmetry between it and the OSC8M where it isn't even an option? And why START validates various other things but not that. Was also under the impression that enabling an output would put it on a pin which is not what I wanted. Oh well.

 

I wish this code was in something like github so I could at least send pull requests to try and make it better. Fix the typos in the tooltips, make the tooltips say something useful that's not just the form label repeated again, put inline help and references to the datasheet on screen, add missing validation, bring in some consistency..