Is the clock and oscillator section of the Atmel SAMD21 just garbage or... - Page 1
Forum section: electronics / general

author: XFDDesign
author_rank: Frequent Contributor
timestamp: September 13, 2016, 02:42:50 pm
content: or am I missing something?I have two Atmel SAMR21 eval boards, which is simply the SAMD21 with the AT86RF233 glued onto the thing. I have the DFLL working at 'about' 48MHz - and about is the key word here. There is serious stability issues from what I'm finding, as the thing looks like it has no lock (device reports it has lock).I've done some tracing back through the part, and noticed that the low-power 32.768kHz clock had a lot of falling-edge jitter, by way of observing GCLK_IO (which I use as my source generator for the DFLL), so I tried the 'high precision' 32.768kHz clock.It also had falling edge jitter.External 32.768kHz crystal? Less jitter, but still jitter. Okay, maybe it's really poor drive level and it's not getting repeatable results.I then forced a 32.768kHz signal into the oscillator pin where I know the stability is good.The falling edge jitter was present. But now, I could compare what was going in, to what was going out. Going in was clean, 50% duty cycle. Coming out was a square wave of about 42% duty cycle. Rising-edge-to-rising-edge was spot on 30.5176..us but falling-edge-to-falling-edge was all over the map. I believe the unstable nature of the 48MHz signal is simply the DFLL tracking the phase errors of the reference oscillator.I went shopping through the errata in the datasheet. No mention of this behavior. Google searching posted one result, where the conclusion of the discussion was that "don't use the DFLL if you need something clean, use the DPLL." I'm not sure that makes sense (haven't tried the DPLL yet) as itlookslike this is an issue of the source oscillator.Has anyone else observed this? Am I just a stunned fuck and am missing something blatantly obvious?

author: tatus1969
author_rank: Super Contributor
timestamp: September 13, 2016, 03:00:51 pm
content: looked into this because I haven't used a DFLL yet. Seems to me that is normal behavior? Had you checked the Atmel community? Found thishttp://community.atmel.com/forum/saml21-dfll-closed-loop-48mhz

author: XFDDesign
author_rank: Frequent Contributor
timestamp: September 13, 2016, 03:16:51 pm
content: It's really bad if this is normal behavior. And you found the only discussion I found on the matter (note that Robin said "My experience with the DFLL is that it is low power, but it comes with noise and jitter. I switched over to use the DPLL instead, and all my problems vanished.")My variance appears to be ±500kHz, which makes for some seriously awful timing if you're needing to do anything with any sort of precision.

author: ataradov
author_rank: Super Contributor
timestamp: September 13, 2016, 03:48:07 pm
content: I can't comment on that rant without more information, but there is a bit GCLK_GENCTRL_IDC (Improve Duty Cycle), you may want to try this.You may also need to check your DFLL tracking settings, your step values may be to big.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: September 13, 2016, 03:51:01 pm
content: Process on trying to correct the defect. "Rant."GCLK_GENCTRL, bit IDC is a fix for odd divisions greater than 1. Attempting to apply the fix on /1 does nothing. /3, /5, etc does.If you use the part, you can comment very easily:Do you get a clean, well behaved 48MHz DFLL output with your code: Y / N ?

author: ataradov
author_rank: Super Contributor
timestamp: September 13, 2016, 03:57:56 pm
content: Quote from: XFDDesign on September 13, 2016, 03:51:01 pmI would have to measure it, since it was never an issue. All the internal things use raising edge of the clock, so failing edge does not really matter. Why is this a problem for you?But to do that, I would need to understand the experiment. If I understand correctly, the last part of your post, you drive GCLK from a stable 32 kHz source, and routing GCLK out to the output and the result is unstable falling edge of the same 32 kHz clock? How does PLL come into play here then?

author: XFDDesign
author_rank: Frequent Contributor
timestamp: September 13, 2016, 04:10:18 pm
content: Signal Flow: -> GEN2 ->  -> GEN0I've tied GEN0..2 to their respective I/O Pins (PA14, PA15, and PA16).I can actually observe the clock behaviors on these pins. From all that I've read, these are not subject to a peripheral clock, they're directly buffered. (I went to look up the DS page, but it isn't where I thought it was. I can follow up on it when I find it).Observing GEN2 (PA16) when it's an output, I can monitor the 32.768kHz output and observe the irregular duty-cycling.Observing GEN0 (PA14), you observe a close-in timebase on the scope, and it looks good. Zoom out to get some density, and you can visibly see a kind of 'beating' where the phase of the clock wanders. Turn on averaging, and you can verify this as a sort of 'attenuation' the further you get away from the trigger point.As to 'why is this a problem,'Timing matters, and a sloppy system clock with a 1% variance is going to introduce problems.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: September 13, 2016, 04:26:57 pm
content: Pulling some tricks, it's a compound problem.Routed a high-accuracy, well behaved 32.768kHz signal to the device, verified no alteration from the generator, then mapped it to the DFLL:(32.768kHz) -> GCLK_IO -> (DFLL) -> GCLK_IOThere is some improvement, but it's not enough. Some amount of the problem is due to the source and some is the DFLL. I'll keep picking at this.

author: ataradov
author_rank: Super Contributor
timestamp: September 13, 2016, 04:30:13 pm
content: So I just took one of my D21 project and enabled DFLL output (sourced from internal ULP32K oscillator), and the output looks clean enough. I think we need to define some measurement procedure that we both follow.The only thing I see when I zoom out on the scope is aliasing at some time bases, but that has noting to do with the signal itself.Also, due to pin bandwidth (~12 MHz), 48 MHz signal basically look like a sine wave.

author: danfo098
author_rank: Contributor
timestamp: September 21, 2016, 11:42:11 am
content: If you don't actually need the precision sometimes a sloppy system clock solves "problems".

author: Franc
author_rank: Regular Contributor
timestamp: September 25, 2016, 12:47:24 pm
content: I got a satisfatory signal out for my DFLL, see attached. I am using XplainedPro Sam D21 board.If you need I can share the bare code.Regards.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: September 27, 2016, 12:30:05 pm
content: You need to zoom out quite a bit. The close-in jitter is low on only a few cycles.The clock concern has taken a back burner to another project in the near term. In the mean time, I'm working to build up a higher precision beat frequency oscillator and will be able to model the output clock's imperfection to a better degree. At this point I've largely just written off the DFLL.