Can't run SAMD11 X PLAINED above 33MHZ

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

Im using ASF4 and Atmel Studio 7.0.1417 with the SAMD11 X PLAINED board.

Im playing around with clocking in the Atmel Start on line aplication.

I downloaded Led Flasher exemple aplication and made some modification to the clock configuration, and every time the clock is above about 33MHZ the aplication does not run any more.

In the last  attempt I was using FDPLL96M, so it was easy to change the clock frequency by altering "DPLL LDR".

Is there a configuration I'm missing?, note that changing only the PLL multiplier makes the aplication run or not according to clock being below or above 33MHZ

This topic has a solution.
Last Edited: Thu. Oct 5, 2017 - 08:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Did you set wait states?

/Lars

 

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

     Not by myself.... I do not Know if the Atmel LED Flasher example did that.

    How do I know that and why is it relevant? I mean, why wait states could prevent the CPU from running.

    Perhaps I'm not clear enough, When I say that its not running above 33MHZ is because its kind of freezing not running slower.

    Once I set the clock above 33MHZ, from the debugger I can see that the CPU resetting after executing few lines in a roll.

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

How do you know that and why is it relevant?  You need to run wait states as the flash is not fast enough to work with the cpu at 48MHz. It's in the documentation. If you don't configure enough wait states, the outcome is as you describe. This has been discussed many times before - especially with SAMD20/21.

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

From the users manual

David (aka frog_jr)

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

Yeah, but if he's using Atmel Start, it should set the wait states for him, right?

 

(No, it doesn't.   Sigh.  What IS it with clock system people that they think reasonable parameters are divisors and fractional divisors and such, instead of target CPU frequencies...)

Last Edited: Wed. Oct 4, 2017 - 09:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like wait states can be set under "PM" in start, one has to "Show system drivers" first.

/Lars

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

   Thank you every body, now I got a clue about the problem.

   First time with ARM, first time with ATSAM, first time with Atmel Studio and ASF, too many "Firsts".

   I Know the relevancy of Wait States, but never crossed my mind that may have meaning inside a micro controller.

   Thank you again for the tip.

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

      I gave that a moment of thought and to me became almost pointless having a 48MHZ CPU with a 24MHZ program memory, at the end the whole system is 24MHZ with a  RISC CPU.

      There may be some instructions with internal processing like multiply that may benefit from 48MHZ clocking  + 1 Wait state, but that is too specific.

      With the amount of knowledge about ATSAM that I have now it seems to me, that is better to clock with 33MHZ without Wait States, may be in the future I discover something that alter this.

 

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

Did you ever think you’re not the first person to have this question? This very topic has been discussed many times and benchmarks performed. You’ll find the manufacturers do a few tricks like 256 bit wide flash to up the speed, so the impact of wait states is not as dramatic as it was in the days of the Z80.
If you dig a bit more you find other insights like the i/o performance of the M0.

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

Also, you can potentially put critical code in RAM, which does not require wait states.  (works for CM3/CM4.  I'm not sure about CM0.)

The modern trend seems to be to allow even slower directly executable memory (external SPI flash, for instance.)

And note that even low-end CM0 products without "accelerators" have flash memory that is 32bits wide (two instructions, usually.)

Sam3X (Arduino Due) requires 4 wait states to operate at 84MHz, but does 128bit fetches.   SAMD5x will have actual cache.

It all makes trying to predict actual execution times at single clock-cycle resolution ... very frustrating, compared to 8bit microcontrollers.