Author Topic: [ATmega 0] clock confusion  (Read 3052 times)

0 Members and 1 Guest are viewing this topic.

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
[ATmega 0] clock confusion
« on: August 25, 2018, 08:35:31 pm »
I am completely confused by the clock setup. In some texts it sounds like the CPU only runs at 16/20MHz and in others that the main prescaler applies to the CPU as well as the peripheries clock.

Also I am playing with TCA0 in split mode doing PWM and I cannot change the main periphery frequency. I cannot disable the main clock prescaler for the periphery clock and I cannot chose any clock prescaler it appears locked on the default /6. I have locked for clarification on the maximum frequency allowed for the CLK_PER but nothing and no time constraints on when it is allowed to be changed either.

I am not liking the microchip documentation one little bit. Some one is so far up their own arseholes they just plain forgot to explain things and direct you down rabbit holes with nothing at the end!
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #1 on: August 25, 2018, 08:40:33 pm »
OK I found the next casual mention of the protection register for changing the clock but i am still confused about the CPU clock - and so is microshit judging by the vagueness of the datasheet.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #2 on: August 25, 2018, 08:58:51 pm »
Right so I can disable the protection to change the prescaler but disabling the protection and then trying to disable it so that I get a clock division of "1" does not work.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #3 on: August 25, 2018, 09:32:00 pm »
After some more digging I found on page 86 of the 0-series manual a very cryptic explanation and hazarded a guess at setting LOCKEN to 0 (or rather the whole register) and this works for disabling the main periphery prescaler but i still don't know what frequency the CPU is running at.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: [ATmega 0] clock confusion
« Reply #4 on: August 25, 2018, 10:40:56 pm »
7.5.7, 7.7.1 CCP

CPU_CCP = 0xD8; //IOREG magic key
//now have 4 cpu instructions to write to protected ioreg

9.2.1

nice color clock diagram

9.3.5

shows which CLKCTRL registers are protected by CCP


9.5.3

Bit 0 – LOCKEN Lock Enable
Writing this bit to '1' will lock the CLKCTRL.MCLKCTRLA and CLKCTRL.MCLKCTRLB registers, and, if
applicable, the calibration settings for the current main clock source from further software updates. Once
locked, the CLKCTRL.MCLKLOCK registers cannot be accessed until the next hardware Reset.
This provides protection for the CLKCTRL.MCLKCTRLA and CLKCTRL.MCLKCTRLB registers and
calibration settings for the main clock source from unintentional modification by software.
At Reset, the LOCKEN bit is loaded based on the OSCLOCK bit in FUSE.OSCCFG.

Once locked, it stays locked until reset
If fuse config is set to lock, cannot change at all
not sure why you are playing around with this bit


so, to turn off prescaller it probably goes something like-
CPU_CCP = CCP_IOREG_gc; //unlock ioreg
CLKCTRL_MCLKCTRLB = 0; //PEN=0 (prescaler off)


No need to dump on Microchip because you have trouble understanding the datasheet and headers.

I know nothing of the mega4809, but I have the datasheet and header just to play along, it looks to me like its pretty good.
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21609
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: [ATmega 0] clock confusion
« Reply #5 on: August 26, 2018, 02:57:54 am »
http://ww1.microchip.com/downloads/en/DeviceDoc/40002015A.pdf page 78 shows the clock architecture.  OSC20M (internal RC osc) I'm guessing is default, routed to everything, at startup.

Yes, you need to do the protection dance to change the register.  This is just a pair of statements back to back, and make sure that they execute within the required time frame (inspect the asm output to verify, and avoid using relational expressions in the assignment -- use a compile-time constant, not bitmasking).

They're saying TCD can run from any of CLK_PER, OSC20M or EXTCLK sources; RTC, WDT and BOD run from only what's shown/selected; and everything else runs from CLK_MAIN / (prescaler value).  There's probably a prescaler setting for both (CPU and PER), then a separate one for CLK_PER only so it can run at the same speed or slower than CPU (think that's how XMEGA did it, anyway).

Whatever it is, RTFDS, it's in there. :)

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: [ATmega 0] clock confusion
« Reply #6 on: August 26, 2018, 04:54:56 am »
Quote
They're saying TCD can run from...
but hardly matters as there is no TCD. It looks like they had a 12bit timer (TCD) planned but removed and didn't completely clean up (a few references in 0 manual, a few in the header)..

Quote
There's probably a prescaler setting for both (CPU and PER), then a separate one for CLK_PER only so it can run at the same speed or slower than CPU
CLK_CPU and CLK_PER both come from the main clock prescaler, so they both are always the same.  So anytime you see a CLK_PER in any peripheral diagram, you are also looking at CLK_CPU.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #7 on: August 26, 2018, 07:43:08 am »



9.5.3

Bit 0 – LOCKEN Lock Enable
Writing this bit to '1' will lock the CLKCTRL.MCLKCTRLA and CLKCTRL.MCLKCTRLB registers, and, if
applicable, the calibration settings for the current main clock source from further software updates. Once
locked, the CLKCTRL.MCLKLOCK registers cannot be accessed until the next hardware Reset.
This provides protection for the CLKCTRL.MCLKCTRLA and CLKCTRL.MCLKCTRLB registers and
calibration settings for the main clock source from unintentional modification by software.
At Reset, the LOCKEN bit is loaded based on the OSCLOCK bit in FUSE.OSCCFG.

Once locked, it stays locked until reset
If fuse config is set to lock, cannot change at all
not sure why you are playing around with this bit


so, to turn off prescaller it probably goes something like-
CPU_CCP = CCP_IOREG_gc; //unlock ioreg
CLKCTRL_MCLKCTRLB = 0; //PEN=0 (prescaler off)


No need to dump on Microchip because you have trouble understanding the datasheet and headers.

I know nothing of the mega4809, but I have the datasheet and header just to play along, it looks to me like its pretty good.

You see because you have not actually done it you don't know either and fell into the same trap of the documentation! You have to disable the LOCKEN even if it is not set in the fuse settings in order to turn the prescaler off!

Further with the prescaler still on with a setting of 2 and TCA0 in split mode running with no prescaler of it's own so at maximum frequency with a top value of 255 you get the expected frequency of 39KHz, now if you tick the box in the fuse settings this becomes 45KHz - WTF? how, why?????
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #8 on: August 26, 2018, 07:56:44 am »
http://ww1.microchip.com/downloads/en/DeviceDoc/40002015A.pdf page 78 shows the clock architecture.  OSC20M (internal RC osc) I'm guessing is default, routed to everything, at startup.

Yes, you need to do the protection dance to change the register.  This is just a pair of statements back to back, and make sure that they execute within the required time frame (inspect the asm output to verify, and avoid using relational expressions in the assignment -- use a compile-time constant, not bitmasking).

They're saying TCD can run from any of CLK_PER, OSC20M or EXTCLK sources; RTC, WDT and BOD run from only what's shown/selected; and everything else runs from CLK_MAIN / (prescaler value).  There's probably a prescaler setting for both (CPU and PER), then a separate one for CLK_PER only so it can run at the same speed or slower than CPU (think that's how XMEGA did it, anyway).

Whatever it is, RTFDS, it's in there. :)

Tim

I don't know Tim, ideally the CPU and the peripherals should have separate clock prescaler settings but apparently not. In one breath they talk about the CPU running off main clock and the prescaler being for the peripherals yet in the datasheet of the actual chip give power consumption examples for 5MHz on the CPU with a prescaler of 4.

Not all peripherals have a prescaler like the TCBn timers except for a /2 so they are locked to the CPU clock it would seem and the only way to get PWM from them is in an 8 bit mode so that is 39KHz at least. These counters being there 3 of might have been put to good use for things like motor control but the timers are very inflexible.

Because i need a PWM at a few hundred Hz I am having to use TCA0 and because there is only the one I am having to split it as I want to control 2 motors and I may as well put them 180 degrees out from each other to reduce the current in any single turn on or turn off event.

So I would have prefered to have the option of the CPU having it's own clock selection so that the CLK_PER could be run at something sensible for the peripherals without a pre-scaler but still have maximum CPU speed.

They have of course neglected to do a diagram of the clock controller and a picture is worth a thousand words particularly when you going to be ambiguous in your words as they have chosen to be.
« Last Edit: August 26, 2018, 08:09:15 am by Simon »
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21609
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: [ATmega 0] clock confusion
« Reply #9 on: August 26, 2018, 09:01:16 am »
Sounds like they're getting increasingly hasty in their designs and documentation, then.  Sad.

All the more reason to use ARM if you need more power/features than a classic mega.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #10 on: August 26, 2018, 09:34:17 am »
well this mega is nice so far other than the stupidity with the clock that for the sake of an extra multiplexer to tap the CPU clock separately from the periphery clock.
if i was running all the interrupts I could I would want the fastest CPU clock. The only reason I would have to reduce the clock would be EMC or power consumption. Apparently these can run at 20MHz at 125C.

I never run on battery so the low power consumption is not an issue. If i had to I'd put a shield over the µC for EMC. Commercial/auto EMC tests are easy, I'd only be concerned about military specs. The other big thing to watch is any high frequency stuff coming out of the pins, these have slew rate control on the pins.

If i can master this little chip, I may have the confidence to take on an ARM.

I have no more interest in the graphical aids offered on some ARM's as the documentation on how to use the resulting code is none existent so I'll have to go bare metal on the registers and there will be a lot of them.
« Last Edit: August 26, 2018, 09:36:39 am by Simon »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #11 on: August 26, 2018, 02:40:10 pm »
The slew rate goes from 10ns to 20ns and the overshoot drops a little, by about half, with the slew rate control enabled.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: [ATmega 0] clock confusion
« Reply #12 on: August 26, 2018, 04:23:44 pm »
FUSE.OSCLOCK - locks CLKCTRL.OSC20MCALIBB (nothing mentioned about LOCKEN)

although mentioned, there is no CLKCTRL.OSC20MCALIBA is seems

CLKCTRL.MCLKLOCK.LOCKEN is supposed to load from FUSE.OSCLOCK (but fuse docs don't seem to indicate this)


You are probably a beta tester then., along with everyone else using this chip. Probably normal when you are the one getting the first batch out of the oven.
When you see registers mentioned but nowhere to be found, or a timer (TCD) that does not exist, I guess you can figure they don't have everything squared away yet.

I would keep my own list of errata (documentation/hardware), verify them thoroughly, and at some point submit them to mchp.
Maybe turn on the clkout so you can always see what clk_per is always doing. Check what actually loads into CLKCTRL.OSC20MCALIBB after reset (maybe related to your 39 vs 45khz error). See if the LOCKEN actually loads from the OSCLOCK fuse. And so on.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #13 on: August 26, 2018, 04:34:36 pm »
well the actual clock can be deduced from the PWM frequency. 45KHz rather than 39KHz does not correspond to any valid prescaler ratio.
 

Offline Zbig

  • Frequent Contributor
  • **
  • Posts: 927
  • Country: pl
Re: [ATmega 0] clock confusion
« Reply #14 on: November 24, 2020, 04:43:10 pm »
Sorry for necroposting but after having needlessly wasted some time on this myself, I thought the topic could use a brief, conclusive summary. Feel free to bin this post if you think otherwise. I won't say anything more that's been already said, just provide a TLDR;

In order for your modifications to CLKCTRL.MCLKCTRLB to stick, first you have to:
  • Clear the LOCKEN bit of the CLKCTRL.MCLKLOCK. Even when you don't set it to 1 with the relevant fuse. Even though you've made sure it's zero by actually reading it. Just do an explicit CLKCTRL.MCLKLOCK = 0x00 regardless. I know. It's not you, it's them :)
  • Disable Configuration Change protection by CPU_CCP = CCP_IOREG_gc. Then you have 4 CPU cycles to alter the CLKCTRL.MCLKCTRLB.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: [ATmega 0] clock confusion
« Reply #15 on: November 24, 2020, 07:29:01 pm »
I have been using avr0/1 for a while (4809,3217,817,etc- they are all the same), its not that complicated-
  write CCP to unlock
  write new value to MCLKCTRLB   (PDIV<<1 | PEN)
and unless you are using -O0 optimization you will get the 4 cycle requirement met.

No need to touch the MCLKLOCK register.


https://godbolt.org/z/hGT7Go
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17728
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: [ATmega 0] clock confusion
« Reply #16 on: November 24, 2020, 08:02:33 pm »
I just never understood why they took the crystal oscillator out or didn't the original xmega have a crystal driver? for this alone I am veering to an ARM device, no point in going backwards, onwards and upwards. I wonder what they plan to do with the legacy AVR's, not waiting around to find out though.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf