Solved: ATTiny 414 & Using 32 kHz External Crystal for Waveform Generation (TCA & TCD)

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

Hi Guys,

 

I'm going to apologize right off the bat, I'm still a beginner when it comes to programming, & I've been learning on the ATTiny 402 & 412. I've recently been programming with the ATTiny 412, & I want to switch to the 414 because of the additional pins & if I need more space, I could upgrade to the 814 quite easily. 

 

The one thing I found appealing about the 414 was that it has the option for a 32 khz external crystal. I've been using an external clock with the 412 to get about  .5% accuracy for PWM frequencies. This has been working well, but external clocks can get quite expensive, & I would rather switch to a crystal if possible to save money. 

 

So my first question is, would it be possible to run the main clock of the MCU at 16/20 MHz while using an external 32 kHz crystal for frequency reference for better accuracy (.5% to 1% accuracy desired)? 

 

The second question, if the above is possible. Would using both TCA and TCD for frequency generation be applicable with the external 32 kHz crystal? The reason I ask is I noticed on the 414 data sheet (page 59) that the 32 kHz external crystal doesn't go to TCD on CLKCSEL. I attached it for reference.

 

Lastly, if all is this possible. What would I need to change in my code in order to run the MCU at 16/20 MHz while using the 32 kHZ ext crystal as a reference for TCA & TCD? I've attached the code to this message.

 

Thanks in advance.

 

-Ankit 

 

 

FUSES = {
    .WDTCFG     = FUSE_WDTCFG_DEFAULT,
    .BODCFG     = FUSE_BODCFG_DEFAULT,
    .OSCCFG     = FREQSEL_16MHZ_gc,     //Select 16MHz OSC
    .TCD0CFG    = FUSE_TCD0CFG_DEFAULT,
    .SYSCFG0    = FUSE_SYSCFG0_DEFAULT,
    .SYSCFG1    = FUSE_SYSCFG1_DEFAULT,
    .APPEND     = FUSE_APPEND_DEFAULT,
    .BOOTEND    = FUSE_BOOTEND_DEFAULT,
};

int main(void)
{     _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_2X_gc | !CLKCTRL_PEN_bm);
    _PROTECTED_WRITE(CLKCTRL.MCLKCTRLA, !CLKCTRL_CLKOUT_bm | CLKCTRL_CLKSEL_OSC20M_gc);

 	/* Set pins as i/o */

	PORTB.OUTCLR = PORTB.DIRSET = PIN0_bm; // output.
	PORTA.OUTCLR = PORTA.DIRSET = PIN4_bm; // output.

    tca_pwm_update(frequency, 0);  // frequency = 505Hz, duty = %
    TCA0.SINGLE.CTRLB  = TCA_SINGLE_CMP0EN_bm | TCA_SINGLE_WGMODE_SINGLESLOPE_gc;
    TCA0.SINGLE.CTRLA  = TCA_SINGLE_CLKSEL_DIV4_gc | TCA_SINGLE_ENABLE_bm;  // Stop until the setting is complete.

    tcd_pwm_update(frequency2, 2532); //This is ASYNCHRONOUS.  frequency = 425Hz, duty = %
    _PROTECTED_WRITE (TCD0.FAULTCTRL, TCD_CMPAEN_bm);
    TCD0.CTRLC = TCD_AUPDATE_bm;    // <--- Not omissible
    TCD0.CTRLB = TCD_WGMODE_ONERAMP_gc;
    while (!(TCD0.STATUS & TCD_ENRDY_bm));
    TCD0.CTRLA = TCD_CLKSEL_SYSCLK_gc | TCD_CNTPRES_DIV4_gc | TCD_SYNCPRES_DIV4_gc | TCD_ENABLE_bm;

 

Attachment(s): 

This topic has a solution.
Last Edited: Wed. Feb 5, 2020 - 01:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you calibrate 16 / 20MHz based on 32kHz crystal, I think you can get the accuracy within 1%.

It is clear from the data sheet what can be used as the clock source for TCA and TCD. There is no way.

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

Thanks kabasan, that was my fear based on the data sheet. I wasn’t sure if there was a way or not, but I figured I would ask.

If calibrating the 16/20 MHz clock based on the 32 kHZ ext crystal dials it to 1% accuracy that should work perfectly fine.

Cheers,
Ankit Patel

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

Well, it's possible to connect the external crystal to the RTC, then the RTC to the event system, and from that enable the event output to generate some wave derived from the 32 kHz crystal.

Then, wire that event output to the external clock input, and from that clock timer D. Crazy but possible cheeky

 

Here is another crazy but possible thing I did once with a tiny1614. You can clock it with a crystal, though I wouldn't recommend it:

https://www.avrfreaks.net/forum/weekend-project-using-event-system-tiny1614-create-full-swing-crystal-oscillator

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

Thanks El Tangas,

 

Yea, I thought using the RTC might be a viable work around since you get can get a waveform from it, I didn't realize how much of a work around it would be lol. 

 

Your reference to the 1614 seems really interesting. In fact, I was wondering if this could have been done on the 412 since it doesn't have OSC1 or OSC2 pins (using a crystal in clock input). 

 

I understand that it is a risk if the crystal stops resonating. That would essentially mess the timing/waveforms on the circuit. Outside of that, is there a reason you wouldn't recommend this approach, & is there a particular reason why you had selected a 18.432 MHz crystal? 

 

Thanks again.

 

 

Cheers,

Ankit Patel

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

Ankit.Patel wrote:
Outside of that, is there a reason you wouldn't recommend this approach, & is there a particular reason why you had selected a 18.432 MHz crystal?

 

It was an experiment, the crystal was from my junk parts bin, just something I had available. I don't recommend it because it causes a lot of noise in the other I/O pins, this is an hack after all, and not something the designers had in mind, I guess.

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

Ankit.Patel wrote:
 I've recently been programming with the ATTiny 412, & I want to switch to the 414 because of the additional pins & if I need more space, I could upgrade to the 814 quite easily. 

This is such a rookie mistake using a small AVR to develop on and then find out it will not fit, and then start over with the next size up...

much better to use the largest member of the family (3214?), develop the app and then look at the requirements to see what chip this will fit on.

If the app size just exceeds a smaller chip then you can put in the effort to shrink the app size to fit, a much better use of time.

Many beginners think the smaller chips are easier to work with, but the larger chips with more resources are actually easier.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Wed. Jan 29, 2020 - 03:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Makes sense El Tangas, thanks for sharing.

Jim,

Guilty as charged, a rookie making rookie moves. If I could go back, I’d definitely start with a larger MCU. I think I’d start with the 1616. 3216 would probably work as well, extra flash never hurts.

Cheers,
Ankit

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

Been there myself, so lesson was learned the hard way!   Good luck with your project.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Hey guys, 

 

Just as a quick update, it looks like I'll be sticking with a standard clock. I was reading the 414 datasheet more this weekend. It looks like for a 32 kHz external crystal, the start-up time is ~300 ms - that's a pretty significant delay! I've used 16-20 Mhz crystals before for other projects without any issues, so it didn't register that a lower frequency crystal would have a significant delay. 

 

Thanks again for the help/advice.

 

Cheers,

Ankit

 

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

A strategy used in old school AVRs involving a 32k crystal is not to actually use it as the main clock source (because if you are sleeping it takes too long to wake up) but to use it as an asynchronous clock on one of the timers then over time use that to calibrate the main internal oscillator (which will start quickly). Not sure if these new style devices allow for a similar strategy ?

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

I'm not 100% sure, I pretty sure you can calibrate the internal clock using a crystal. However, I'm not sure if that calibration occurs over time or just once the crystal starts-up after each use? My assumption was once the MCU is off, the clock will need to be recalibrated once powered back-on. 

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

Ankit.Patel wrote:

Just as a quick update, it looks like I'll be sticking with a standard clock. I was reading the 414 datasheet more this weekend. It looks like for a 32 kHz external crystal, the start-up time is ~300 ms - that's a pretty significant delay! I've used 16-20 Mhz crystals before for other projects without any issues, so it didn't register that a lower frequency crystal would have a significant delay. 

Yes, the 32kHz xtals can take a while to 'start up', but usually that is only at first power up, you do not run with the 32kHz on/off/on....

Ankit.Patel wrote:

I'm not 100% sure, I pretty sure you can calibrate the internal clock using a crystal. However, I'm not sure if that calibration occurs over time or just once the crystal starts-up after each use? My assumption was once the MCU is off, the clock will need to be recalibrated once powered back-on. 

Such calibrate is usually done by user SW, and to catch drift, you need to do it somewhat frequently.

Common is something like 'After N edges of 32kHz, capture SysCLK edges in some timer' - some MCUs can do that in HW, some need an interrupt.

You can work out the quantize effects : 

 A single 32kHz cycle can give one part in 244 on 8MHz

 1 in 256 edges will capture 62500 from a 8MHz sysclk, which resolves to ~16ppm