XMega HighRes PWM - irgendwie nicht so HighRes

[Johannes N. (strangeman)]

Hallo!

Ich beschäftige mich gerade mit der HighRes extension des Timers in 
einem Xmega128A3.
Der soll eine einfache (single-slope) PWM mit 10bit an PORTD:0-3 
erzeugen - und das möglichst flink. Dazu habe ich die HighRes extension 
eingeschaltet und die Clocks so configuriert, dass Fper4 auf 128MHz 
läuft und die CPU auf 32MHz.
Auf dem Oszi sehe ich schön meine PWM mit 125kHz. Im Datenblatt steht, 
dass Werte kleiner als 4 keinen Output erzeugen, das leuchtet mir im 
anbetracht der allgemeinen Funktionsweise des HighRes Moduls ein. Ich 
kann das Verhalten auch am Oszi sehen.

Was ich aber ebenfalls sehe, ist dass die Werte 4,5,6,7 allesamt die 
selbe Wellenform erzeugen, ebenso die Werte 8,9,10,11 usw.
De facto ist der Output also in nur 4er Schritten einstellbar. Warum?! 
Dann hätte ich ja gleich meine PWM Auflösung um 2bit verringern und den 
Timer ohne HighRes Extension betreiben können.

Hier kommt mein Code.

/** initializes the 4 pwm outputs.
 **/
void pwm_init( void )
{
  // set pins to output
  PORTD.DIRSET = PIN0_bm | PIN1_bm | PIN2_bm | PIN3_bm;
  // enable all four outputs, single slope PWM
  TCD0.CTRLB = TC0_CCAEN_bm | TC0_CCBEN_bm 
        | TC0_CCCEN_bm | TC0_CCDEN_bm
        | TC_WGMODE_SS_gc;
  // configure 10bit operation
  TCD0.PER = 1023;
  // configure highres option (128MHz base speed)
  HIRESD.CTRLA = HIRES_HREN_BOTH_gc;
  
  // enable the timer
  TCD0.CTRLA = TC_CLKSEL_DIV1_gc;
  
  // set dummy values
  TCD0.CCABUF = 512;
  TCD0.CCBBUF = 256;
  TCD0.CCCBUF = 128;
  TCD0.CCDBUF = 64;

}

/** sets a channel to the desired value
 * @param channel   channel number (0-3)
 * @param value    channel value (0-1024)
 **/
 void pwm_setChannel(uint8_t channel, uint16_t value)
 {
   // no values > 1023 allowed!
   value = (value > 1023)?1023:value;
   
   switch (channel)
   {
     case 0: TCD0.CCABUF = value; break;
     case 1: TCD0.CCBBUF = value; break;
     case 2: TCD0.CCCBUF = value; break;
     case 3: TCD0.CCDBUF = value; break;
     default: break;
   }
 }

Danke für eure Hilfe!
Johannes

[Thomas F. (tomasf)]

Dein Code sieht soweit OK aus

Hier solltest du das nur für den Timer einschalten, den du auch benutzt.

 HIRESD.CTRLA = HIRES_HREN_BOTH_gc;

Der Fehler liegt also wahrscheinlich in deinem anderem Code.

Es gibt auch eine Atmel Appnote zu Hires/Awex mit Beispiel, im Zweifel 
kannst du damit anfangen.

[Johannes N. (strangeman)]

Hi Thomas,

ist es relevant, ob ich tatsächlich beide Timer verwende?
später soll auch der andere Timer hinzukommen, daher habe ich das Bit 
schon gesetzt, auch wenn der Timer noch nicht läuft. Du hast Recht, 
vielleicht spinnt die HiRes Extension, wenn einer der beiden Timer nicht 
läuft.
Wenn ich zuhause bin, probiere ich nochmal, ob es geht, wenn ich den 
Hires nur für den einen Timer einschalte.

Die Appnote habe ich gelesen, nur die macht einfach genau das selbe wie 
ich (abgesehen von dem Fehler, den du beschrieben hast)

Ich frage mich allerdings, wie die Ports betrieben werden. Die haben ja 
auch irgendeine Art von Taktung. Wenn die Ports nur mit 32MHz geupdatet 
werden, dann würde mein Ergebnis nicht verwundern. Aber dann wäre eben 
auch die ganze HiRes Extension sinnlos.

[Thomas F. (tomasf)]

Das Timer-Bit sollte egal sein, aber wenns nicht funktioniert, würde ich 
es erstmal auschalten.

Ich habe Hires(+Awex) bereits verwendet und es funktioniert, wie es soll 
(auch nachgemessen) (mit xmegaA4U)

sonst:
-Clockeinstellungen Ok?
-xmega A3 oder A3U?, die U-Serie hat weniger Bugs

[Johannes N. (strangeman)]

Es ist die A3 serie. Ich schau mal auf der Atmel Seite, obs irgendwo 
known bugs gibt. EDIT: Es gibt ja einen haufen Errata, aber leider steht 
nix zum HiRes drin. Die A3U serie scheint ja weitestgehend Bugfrei zu 
sein.

Hier ist der Code, mit dem ich die Clocks initialisiere. Ich finde 
keinen Fehler darin.

static void clock_init(void)
{
  // configure external 16MHz crystal, low power mode on 32kHz external crystal,
  // 16k cycles startup time
  OSC.XOSCCTRL = OSC_FRQRANGE_12TO16_gc | OSC_X32KLPM_bm | OSC_XOSCSEL_XTAL_16KCLK_gc;
  
  // enable external clock, keep internal 2MHZ clock running (it is still used!)
  // all other clocks disabled
  OSC.CTRL = OSC_XOSCEN_bm | OSC_RC2MEN_bm;
  
  // PLL clock source: external clock; factor: 8 => 128MHz output
  OSC.PLLCTRL = (OSC_PLLSRC_XOSC_gc | (8 & OSC_PLLFAC_gm));
  
  // wait for external clock to be ready
  while (!(OSC.STATUS & OSC_XOSCRDY_bm));
  
  // enable PLL
  OSC.CTRL |= OSC_PLLEN_bm;
  
  // wait for pll to be ready
  while (!(OSC.STATUS & OSC_PLLRDY_bm));
  
  // protect during prescaler change
  CCP = CCP_IOREG_gc;
  // set Prescalers:
  // Prescaler A: factor 1 => clk_4 runs at 128MHz
  // Prescaler B: factor 1/2 => clk_2 runs at 64MHz
  // Prescaler C: factor 1/2 => cpu and periphery runs at 32MHz
  CLK.PSCTRL = CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc;
  
  // protect during clock source change
  CCP = CCP_IOREG_gc;
  // switch clock source to PLL
  CLK.CTRL = CLK_SCLKSEL_PLL_gc;
  
  // Turn off int. RC osc.
  OSC.CTRL &= ~OSC_RC2MEN_bm;
}

[Thomas F. (tomasf)]

Der Code für die Clock scheint OK zu sein.

Den hier benutzte ich mit 8Mhz-Quarz

OSC.XOSCCTRL = OSC_FRQRANGE_2TO9_gc | OSC_XOSCSEL_XTAL_16KCLK_gc; 
OSC.CTRL |= OSC_XOSCEN_bm;
while (!(OSC.STATUS & OSC_XOSCRDY_bm)); 

CCP = CCP_IOREG_gc;
CLK.PSCTRL = CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc; 
  
OSC.PLLCTRL = OSC_PLLSRC_XOSC_gc | 16; 
OSC.CTRL |= OSC_PLLEN_bm;
while (!(OSC.STATUS & OSC_PLLRDY_bm));
  
CCP = CCP_IOREG_gc;
CLK.CTRL = CLK_SCLKSEL_PLL_gc;

Dann kannst Du eigentlich nur noch genau das Atmel-Beispiel ausprobieren 
und sehen, was da raus kommt.

[Johannes N. (strangeman)]

Hi Thomas,

ich habe jetzt den HiRes nur für TC0 aktiviert und das Problem bleibt 
bestehen.

Interessanterweise erhalte ich neuerdings ziemlich starken Jitter, der 
aber besteht, egal ob ich HiRes für einen oder für beide Timer 
einschalte. Anbei ein Foto.

Evtl. muss ich mich mal direkt an Atmel wenden? Die Appnote macht, wie 
gesagt, das selbe wie ich. Vielleicht sollte ich das mal 
sicherheitshalber kompillieren und schauen, was passiert...

[Johannes N. (strangeman)]

Ich habe gerade nochmal das Beispiel aus der Appnote getestet. Es 
funktionierte auf Anhieb. Allerdings lief die CPU da auf 8MHz und die 
Timer auf 32MHz. Also habe ich meinen Clock-initialisierungs Code 
eingefügt. Es ging immer noch.

Jetzt habe ich allerding etwas eigenartiges bemerkt und würde mich 
freuen, wenn jemand es nachprüfen kann. Folgenden Code verwende ich:

// include file aus der Appnote AVR1311
#include "avr_compiler.h"


/* Prototyping of functions. */
void ConfigClockSystem( void );

int main( void )
{

  ConfigClockSystem();

  /* Enable output on PORTD. */
  PORTD.DIR = 0xFF;

  // enable all four outputs, single slope PWM
  TCD0.CTRLB = TC0_CCAEN_bm | TC0_CCBEN_bm | TC_WGMODE_SS_gc;
  // configure 10bit operation
  TCD0.PER = 1023;
  // configure highres option (128MHz base speed)
  HIRESD.CTRLA = HIRES_HREN_TC0_gc;
  
  // enable the timer
  TCD0.CTRLA = TC_CLKSEL_DIV1_gc;

  TCD0.CCABUF = 4; // hier verschiedene Werte einsetzen!!
  TCD0.CCBBUF = 5;

  do {
  } while (1);
}


void ConfigClockSystem( void )
{
  // configure external 16MHz crystal, low power mode on 32kHz external crystal,
  // 16k cycles startup time
  OSC.XOSCCTRL = OSC_FRQRANGE_12TO16_gc | OSC_X32KLPM_bm | OSC_XOSCSEL_XTAL_16KCLK_gc;
  
  // enable external clock, keep internal 2MHZ clock running (it is still used!)
  // all other clocks disabled
  OSC.CTRL = OSC_XOSCEN_bm | OSC_RC2MEN_bm;
  
  // PLL clock source: external clock; factor: 8 => 128MHz output
  OSC.PLLCTRL = (OSC_PLLSRC_XOSC_gc | (8 & OSC_PLLFAC_gm));
  
  // wait for external clock to be ready
  while (!(OSC.STATUS & OSC_XOSCRDY_bm));
  
  // enable PLL
  OSC.CTRL |= OSC_PLLEN_bm;
  
  // wait for pll to be ready
  while (!(OSC.STATUS & OSC_PLLRDY_bm));
  
  // protect during prescaler change
  CCP = CCP_IOREG_gc;
  // set Prescalers:
  // Prescaler A: factor 1 => clk_4 runs at 128MHz
  // Prescaler B: factor 1/2 => clk_2 runs at 64MHz
  // Prescaler C: factor 1/2 => cpu and periphery runs at 32MHz
  CLK.PSCTRL = CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc;
  
  // protect during clock source change
  CCP = CCP_IOREG_gc;
  // switch clock source to PLL
  CLK.CTRL = CLK_SCLKSEL_PLL_gc;
  
  // Turn off int. RC osc.
  OSC.CTRL &= ~OSC_RC2MEN_bm;
}

Nun setzt man in der main() am Ende verschiedene Werte ein und 
beobachtet die zwei Ausgänge am Oszi.

Variante 1 (siehe Bild 1)

TCD0.CCABUF = 4; // hier verschiedene Werte einsetzen!!
TCD0.CCBBUF = 0;

Alles okay.

Variante 2 (siehe Bild 2)

TCD0.CCABUF = 5; // hier verschiedene Werte einsetzen!!
TCD0.CCBBUF = 0;

Alles okay. HiRes offensichtlich aktiv.

Variante 3 (siehe Bild 3)

TCD0.CCABUF = 4; // hier verschiedene Werte einsetzen!!
TCD0.CCBBUF = 4;

Alles okay.

Variante 4 (siehe Bild 4)

TCD0.CCABUF = 5; // hier verschiedene Werte einsetzen!!
TCD0.CCBBUF = 5;

Alles okay. HiRes offensichtlich aktiv.

Variante 5 (siehe Bild 5)

TCD0.CCABUF = 4; // hier verschiedene Werte einsetzen!!
TCD0.CCBBUF = 5;

MOMENT! Was ist mit Channel 2 passiert? Der ist auch auf 4 runter 
gegangen!


Das riecht mir doch stark nach einen Bug.
Kann das jemand bestätigen?

PS: Das erklärt auch den (verdächtig in 4er Schritten quantisierten) 
Jitter in meiner vorherigen Messung: Ich habe Channel 2 gemessen (TCCB). 
Auf TCCA lief parallel eine Rampenfunktion, welche in jedem zyklus den 
Wert in Compare register um eins erhöht hat und damit alle Werte 
durch-scannt. Immer, wenn Channel 1 also die Werte 4,5,6,7 angenommen 
hat, ging channel 2 mit. Daher der Jitter. War das verständlich erklärt?

[Thomas F. (tomasf)]

Ich hab deinen Code mal laufen lassen.
xmegaA3, PORTF

Ich würde mal sagen, das funktioniert.

Edit: Du hast auf jeden Fall ein Problem mit der Signalqualität (anderer 
Code?, Port kaputt?) (vllt. liegt 'bessere' Darstellung am Oszi)

[Johannes N. (strangeman)]

Danke dir für's Ausprobieren. Schon mal gut zu wissen, dass es 
prinzipiell funktioniert.
Ich werde nochmal den selben Code für andere Ports probieren. Vielleicht 
gehts ja aus irgendeinem komischen Grund nur bei PortD nicht.

Hmm. Problem mit der Signalqualität? Für mich sieht das eher nach einem 
hochauflösenderen Oszi aus. Meins kann 100MHz (analoge Bandbreite). Wie 
siehts bei deinem aus? Vielleicht bekommen wir deswegen andere 
Signalverläufe. Die Flankensteilheit spricht jedenfalls dafür.

[Thomas F. (tomasf)]

> Hmm. Problem mit der Signalqualität? Für mich sieht das eher nach einem
> hochauflösenderen Oszi aus. Meins kann 100MHz (analoge Bandbreite).

Das wird wohl stimmen.

> Wie
> siehts bei deinem aus?

Abtastrate entspricht Hires-Frequenz, sodass man immerhin die 
Unterschiede noch sehen kann.

[Johannes N. (strangeman)]

Ich habe noch ein wenig weiter untersucht.
Meines Wissens funktioniert die HiRes Extension so: Der Timer schaltet 
die Pins wie bei einer normalen PWM und zählt dabei in 4er Schritten 
aufwärts. Die HiRes Extension springt dann ein, wenn der Timer den Pin 
low schalten würde und verlängert die High-Phase noch ein wenig, sodass 
die feine Abstufung entsteht. Bei einem CC-Wert von z.B. 9 würde der 
Timer selbst bei Schritt 8 den Pin abschalten, die HiRes Extension hält 
den Pin dann aber noch einen weiteren Schritt high.

Soweit ich das überblicke, scheint die grobe Einstellung durch den Timer 
selbst zu funktionieren. Die feine Abstufung in 4er Schritten, die die 
HiRes Extension vornimmt, scheint aber für alle Kanäle synchronisiert zu 
sein - was ja nicht dem Sinn der Sache entspricht.
Grundsätzlich bedeutet das, dass Channel B die gleiche Anzahl an feinen 
HiRes Stufen erhält, wie Channel A.

Hier nochmal einige Beispiele:

+------+----------------------+----------------------+
|      | Eingestellter Wert   | Tatsächlicher Wert   |    
| Nr.  +----------+-----------+----------+-----------+
|      | Chan A   | Chan B    | Chan A   | Chan B    |
+------+----------+-----------+----------+-----------+
|  1   | 4        | 5         | 4        | 4         | 
|  2   | 5        | 5         | 5        | 5         | 
|  3   | 9        | 5         | 9        | 5         |
|  4   | 9        | 4         | 9        | 5         |
|  5   | 4        | 9         | 4        | 8         |

Bemerkungen:
1 - HiRes-Schritte von Chan B zu Chan A synchronisiert
2 - gleiche Anzahl an HiRes Schritten, daher kein Problem
3 - gleiche Anzahl an HiRes Schritten, daher kein Problem
4,5 - HiRes-Schritte von Chan B zu Chan A synchronisiert

Das Problem tritt bei mir an mehreren Ports auf.

EDIT: Bei dir auf einem A3 läuft es. Ich verwende den A3U. Vielleicht 
könnte nochmal jemand mit einem A3U meinen Code von oben testen?
EDIT2: Haha, das quality inquiry Formular auf atmel.com ist offline mit 
einen 404 error. Prima.

[Johannes N. (strangeman)]

Mir ist gerade aufgefallen, dass ich im makefile die ganze Zeit den 
atxmega128a3 angegeben habe, aber den atxmega128a3_U_ verwende. Jetzt 
habe ich nach langem Suchen endlich Pakete der avr-libc gefunden, die 
den atxmega128a3_U_ beinhalten. Allerdings sagt dann avrdude, er kenne 
kein Bauteil mit diesem Namen. Ich verwende eine veraltete Version von 
avrdude (5.11) weil alle neueren Versionen meinen LUFA-basierten 
PDI-Programmer nicht mehr unterstützen. MANN. deadlock.

Bevor ich jetzt einen neuen Programmer kaufe, damit ich eine neuere 
Version von avrdude verwenden kann, wollte ich erstmal sichergehen, ob 
es überhaupt einen Unterschied macht, ob ich für die U version übersetze 
oder für die nicht-U version.

Die includefiles (iox128a3.h bzw. iox128a3u.h) scheinen jedenfalls kaum 
Unterschiede zu haben.

PS: habe jetzt die datei /etc/avrdude.conf manuell editiert und dem 
avrdude die U version beigebracht. Die Device ID ist bei beiden gleich, 
also musste einfach nur der Absatz des 128A3 kopiert werden. Jetzt 
konnte ich meine Firmware endlich für den 128a3_u_ übersetzen und auf 
den chip brennen. Es hat sich aber an meinem problem dadurch nichts 
geändert.

[Thomas F. (tomasf)]

Benutzt du die aktuelle Atmel-Toolchain? (die Atmel Studio benutzt) 
Falls nicht, würde ich das damit noch mal testen. Optimierung -Os oder 
-O1.

Wenn man sich sicher ist, es ist ein Device-Bug, ist es dann dann oft 
doch "nur" ein Compilerbug.

[Johannes N. (strangeman)]

Habe es eben nochmal mit der aktuellen toolchain des Atmel Studio 
probiert. Das Problem bleibt bestehen

[Ingo L. (corrtexx)]

Dann scheint es sich wirklich um einen Bug zu handeln

[Johannes N. (strangeman)]

Hi Ingo,

hättest du evtl die Möglichkeit, den Fehler zu reproduzieren?

[Johannes N. (strangeman)]

Ich habe hier gerade den AtXmega128a1u verlötet und die HiRes-Extension 
funktioniert anstandslos. Es scheint also ein spezifisches Problem des 
xmega128a3u zu sein.

[W. Nickel (Gast)]

@Johannes: vielen Dank für die Erklärung mit dem Rest, den die HIRES 
übernimmt.

Ich habe den ATXMega32A4U und beobachte das gleiche Problem: die 
HIRES-Extension funktioniert nur auf Kanal A. Ich benutze Kanal A und 
Kanal B des Timers TC0 für eine H-Brücke, wobei Kanal A die Linke Hälfte 
(positive Welle) und Kanal B die rechte Hälfte (negative Welle) 
übernehmen (jeweils immer nur ein Kanal an).

Folgender einfacher code (wird alle Paar ms aufgerufen):

if(vset < vact){
  if(TCC0_CCB){
    TCC0_CCBBUF--;
  } else {
    if(TCC0_CCA < MAX_VREG_TERM) TCC0_CCABUF++;
  }
} else if(vset > vact){
  if(TCC0_CCA){
    TCC0_CCABUF--;
  } else {
    if(TCC0_CCB < MAX_VREG_TERM){
      TCC0_CCBBUF++;
    }
  }
}

Auf dem Scope ist die Linke Welle glatt und geschmeidig und die rechte 
gestuft.

Dank deiner Erklärung habe ich für meine Anwendung einen Workaround 
gebastelt: ich schreibe in Kanal A die unteren zwei Bits des Kanals B, 
wenn Kanal B benutzt wird (dann ist in meinem Fall Kanal A ungenutzt und 
eh immer 0).

if(vset < vact){
  if(TCC0_CCB){
    TCC0_CCBBUF--;
    TCC0_CCABUF = TCC0_CCBBUF & 0x0003; // HiRes workaround
  } else {
    if(TCC0_CCA < MAX_VREG_TERM) TCC0_CCABUF++;
  }
} else if(vset > vact){
  if(TCC0_CCA){
    TCC0_CCABUF--;
  } else {
    if(TCC0_CCB < MAX_VREG_TERM){
      TCC0_CCBBUF++;
      TCC0_CCABUF = TCC0_CCBBUF & 0x0003; // HiRes workaround
    }
  }
}

Nun sind beide Wellen hoch aufgelöst. Die zwei unteren Bits auf Kanal A 
stören übrigens nicht, weil die HiRes erst ab 4 funktioniert.