Atmega128A timer0 Fast PWM mode not showing on debug is AS7

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

I'm configuring timer0 on an Atmega128a like so:

TCCR0 |= ((1<<WGM01)|(1<<WGM00)); // Fast PWM
TCCR0 |= (1<<COM01);              // Set OC0 on compare match
TCCR0 |= (1<<CS00);               // No pre-scaling

When running the code in debug mode, it will show up as CTC while the datasheet shows that if both WGM00 + WGM01 are set, fast PWM is chosen.

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

slow_rider wrote:
When running the code in debug mode,

What do you mean by that?  Does that mean you are using a simulator?  An ICE?

 

>>What<< "shows up as CTC"?

 

With all the |=, no one can really say what the contents of that I/O register is.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Sep 25, 2017 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Running in debug mode with an Atmel ICE

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

The debugger will be using this:

      <value-group caption="" name="WAVEFORM_GEN_MODE">
        <value caption="Normal" name="VAL_0x00" value="0x00"/>
        <value caption="PWM, Phase Correct" name="VAL_0x02" value="0x02"/>
        <value caption="CTC" name="VAL_0x01" value="0x01"/>
        <value caption="Fast PWM" name="VAL_0x03" value="0x03"/>
      </value-group>

which agrees with :

 

 

 

On the surface that all looks correct. Does the actual bit display in the register show both bits 6 and 3 to be set?

 

Can you check your ATDF file and make sure it is up to date? The bit I quoted at the top of this post was a download I just made from:

 

http://packs.download.atmel.com/

 

So I guess the ATmega128.atdf I was looking at *is* the latest.

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

I have the same table on the newer format datasheet found here: http://www.atmel.com/Images/Atmel-8151-8-bit-AVR-ATmega128A_Datasheet.pdf

I don't think the code is hard to read or if the value of the register is that important for the question?

Anyway, WGM0x bits are both set so the operating mode should be 3 => Fast PWM.

COM01 is also set so the OC0 pin should toggle.

 

Both WGM01 & 00 are set in code & are shown as set on the debug window. I am not near my computer right now but I'll upload a picture of this when I get home.

 

Last Edited: Mon. Sep 25, 2017 - 09:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using Atmel Studio version:

 

Here is the info in the I/O window before and after setting timer0 mode:

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

Notice how the caption just says "Waveform Generation Mode 0" ? That seems to relate directly to:

        <register caption="Timer/Counter Control Register" name="TCCR0" offset="0x53" size="1">
          <bitfield caption="Force Output Compare" mask="0x80" name="FOC0"/>
          <bitfield caption="Waveform Generation Mode 0" mask="0x40" name="WGM00" values="WAVEFORM_GEN_MODE"/>
          <bitfield caption="Compare Match Output Modes" mask="0x30" name="COM0"/>
          <bitfield caption="Waveform Generation Mode 1" mask="0x08" name="WGM01"/>
          <bitfield caption="Clock Selects" mask="0x07" name="CS0" values="CLK_SEL_3BIT"/>
        </register>

The values= on that line is presumably what ties this to:

      <value-group caption="" name="WAVEFORM_GEN_MODE">
        <value caption="Normal" name="VAL_0x00" value="0x00"/>
        <value caption="PWM, Phase Correct" name="VAL_0x02" value="0x02"/>
        <value caption="CTC" name="VAL_0x01" value="0x01"/>
        <value caption="Fast PWM" name="VAL_0x03" value="0x03"/>
      </value-group>

So, because it only seems to be considering one bit rather than two then it could only ever take the values 0x00 or 0x01 which would be "Normal" or "CTC" but not 0x02="PWM, Phase Correct" or 0x03="Fast PWM"

 

On the surface that does look like a fault in the XML - it should somehow be told that "WAVERFORM_GEN_MODE" is determined by WGM01 as well as WGM00.

 

Wonder that the .ATDF for other devices look like in this regard?

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

What is an effective way to report this to Atmel?

 

BTW, what is going on two lines below that?

 <bitfield caption="Waveform Generation Mode 1" mask="0x08" name="WGM01"/>

It seems to deal with WGM01, separately. Also note that "Waveform Generation Mode 1" does not exist in the I/O window.

Timer2 has a similar field called ""Waveform Generation Mode (TCCR2)".

 

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

slow_rider wrote:
What is an effective way to report this to Atmel?
You just have - no doubt Morten will be along in a minute to explain how this is supposed to work.
slow_rider wrote:
It seems to deal with WGM01, separately. Also note that "Waveform Generation Mode 1" does not exist in the I/O window.
As the tag name suggests each entry here defines a separate bit field. I think the complication here is that WGM00 and WGM01 are not adjacent in the byte but split as bits 3 and 6.

 

I would have expected to see something in the XML that ties the two bits together. Now it may be that the common "WGM0" is what ties them together but I guess we need to hear from Morten about how that is supposed to work?

slow_rider wrote:
Timer2 has a similar field called ""Waveform Generation Mode (TCCR2)".
And does the debug display work or does it fail in similar fashion for that one?

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

Same same...

I've set WGM2x bits using the following command:

TCCR2 |= _BV(WGM21)|_BV(WGM20);

The blocks that represent them are filled, however the WF gen. mode shows as CTC.

 

Last Edited: Mon. Sep 25, 2017 - 04:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well at least the bug is only in the eye candy rather than in anything that really matters ;-) 

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

Well, I guess it's story time ... :) 

 

In ATDF, we model these 'non-contiguous' memory regions using a bitfield mask. This then should be reflected in the value-group element. However, there's a minor hitch during header generation (think this is for the AVR1000 headers, i,e XMEGA) where this get's a tad funky. So, to mop this under the carpet, we manually split this into 2 disjoined bitfields, each with 1 bit each and the full name (the header generator can add the 0-n suffix on multi-byte bitfields if it's a field that is meant to be bit-addressable. 

 

So, what you see here is a 'path of least resistance and not completely silly output' solution we did at the time (but as you noticed, it goes wrong when the IP view tries to present it with named values)... 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

So is this something you are going to fix at some point?

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

... maybe? It's in our bugtracker (DEVXML-1332), but it's a bigger problem than it looks to fix this...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

I guess it'd be too much trouble to simply switch it off and let the developer work it out the old fashioned way? No display is probably better than one that says the wrong thing as it's going to probably be beginners who rely on this kind of eye candy;-)

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

clawson wrote:

I guess it'd be too much trouble to simply switch it off and let the developer work it out the old fashioned way? No display is probably better than one that says the wrong thing as it's going to probably be beginners who rely on this kind of eye candy;-)

 

Oh come on, a nice IDE is important!

 

Every-time I need to work in Keil I hate it, not because it's a bad IDE but because it's ugly and looks like something from the  90's.

Atmel Studio is a strong selling point for AVRs. Look at how horrible MPLAB and other popular MCU IDEs are. The fact you can have the I/O view and plugins is great!

I remember when it was AVR Studio with the same general idea and how it made me prefer Studio to other IDEs which I could also get for free or almost for free as a student.

Software is as important, and sometimes more than the MCU, and in this day and age - you bet! Look how pretty and featured are modern IDEs - Pycharm for example.

You can always write everything is notepad, but why?!?