3
\$\begingroup\$

Looking at an ATMEL SAM4E and I'm looking at the schematic checklist published by Atmel for the SAM4E and the schematic for the SAM4E-EK developer board.

SAM4E checklist SAM4E-EK Design files (including PDF)

enter image description here

enter image description here

The checklist uses 10uH, 1R and 4.7uF for VDDPLL And the developer board uses 56uH, 2.2R and 22uF for VDDPLL.

It would seem clear that checklist is a recommendation and the the developer board is a working example, but how does one select these values ?

  • Will the developer version work for all situations ?
  • When would it not work ?
  • For an arbitary board, what information is needed before hand in order to select the values for these components ?
  • Is it just experimentation ?(ie, during the prototype stage, just try different things until you get good results and then go into production with those?)
\$\endgroup\$
  • 1
    \$\begingroup\$ seems like pretty heavy filtering hey? I came across the same situation when looking at the SAM3S series dev board and the associated checklist documents. This is what I ended up with for my own custom PCB using the SAM3S4 dropbox.com/s/7hz62wga1czvv54/VPLL.JPG?dl=0 \$\endgroup\$ – KyranF May 8 '15 at 2:34
  • \$\begingroup\$ was a ferrite bead/chip inductor \$\endgroup\$ – KyranF May 8 '15 at 2:36
  • \$\begingroup\$ @KyranF did you just randomly (random within reason) pick those values and it ended up working or was there a process involved ? \$\endgroup\$ – efox29 May 8 '15 at 2:36
  • \$\begingroup\$ I honestly can't remember because it was close to 2 years ago that I designed it, but the result "worked". The board contained a 1.2MHz boost converter and was intended to run two small DC motors via integrated H bridge and a servo, however I have not actually done full system testing in those conditions yet to say to you "yes it works perfectly the way i've done it" \$\endgroup\$ – KyranF May 8 '15 at 2:45
  • \$\begingroup\$ I HAVE tested it working fine with a single larger DC motor and program running on the MCU, + temperature sensor ADC readings streamed over USB as a CDC serial port. \$\endgroup\$ – KyranF May 8 '15 at 2:46
3
\$\begingroup\$

-- "Old" question, I know, but still wanted to answer, on this, the eve of my return --

The filtering is most likely intended to keep the VDDCORE noise out of the VDDPLL, to increase its accuracy.

As such the values are probably calculated for its likely-to-be-used core clock speed.

Usually in the Design Checklist they use values that are calculated and rounded to known values that offer slightly better filtering. Of course, it is up to you or any other designer to decide if you can do with less filtering (because your core speed is going to stay above a certain level, for example), or need more (because you will also use lower speeds or heavy I/O at lower speeds).

Generally Atmel's dev-board engineers try to err on the safe side, so I can imagine them just upping the filtering properties.

The series R on the large cap is a little smothering trick, whose value is generally dictated inside a reasonable window by the cap (and inductor)'s sizes, so it's no real wonder the R increases, although not exactly to the same factor.

If you want you can try to leave out the filtering, but you should expect some clock jitter here and there, whether that's a problem for you, is up to you. Although some of the hardware in the SAM might very much not like the jitter in a bad way, so if you're not sure what the parameters on that are for all the internals you will be activating, best to keep the filtering in.

Want to be safe? Take the dev-board values. Want a calculated good value at slightly lower component cost? The design guide will do you just fine in just about all cases I can vividly imagine.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.