ATmega644: Timer2_COMPA_vect wird falsch ausgelöst

[A. P. (adrian_p)]

Hallo zusammen

Ich implementiere gerade eine Strommessung für einen 
Brushless-Controller. Hierzu ist es von Nöten quasi die "Mitte" einer 
PWM-Phase zu ermitteln.

Da zwar einen Overflow-Interrupt aber kein Top-Interrupt vorhanden ist, 
benutze ich den Compare-Match-Interrupt A mit OCR2A = 255. Mein Problem 
ist, dass dieser aus einem mir unerfindlichen Grund zwar ausgeführt 
wird, sich aber kein Bisschen an OCR2A hält.

Die Initialisierung erfolgt folgendermassen:

inline void PWM_init()
{
  //MOSFET-Pins
  DDRD |= (1<<M_AP) | (1<<M_BP) | (1<<M_CP);
  DDRC |= (1<<M_AN) | (1<<M_BN) | (1<<M_CN);
  
  //Timer 1 (16Bit): PhaseCorrect-PWM, 8bit bis 255
  TCCR1A = (0<<WGM11) | (1<<WGM10) | (1<<COM1B1) | (1<<COM1A1);
  TCCR1B = PRESCALER_1;

  //Timer 2 (8Bit): PhaseCorrect-PWM bis 255
  TCCR2A = (0<<WGM21) | (1<<WGM20) | (1<<COM2B1);
  TCCR2B = PRESCALER_1_Timer2;
  
  //Compare-Match Interrupt der Strommessung
  OCR2A = 255;
}

Der PWM-Wert (bei Timer2 wird hierzu einfach nur OCR2B benutzt) wird 
live gesetzt. Sobald ein AC-Interrupt der sensorlosen Motor-Steuerung 
erfolgt, läuft eine Phase-Erkennung durch. Jede Sekunde wird nun der 
Compare-Match Interrupt (TOP_INT_ON) eingeschaltet:

ISR(ANALOG_COMP_vect)
{  
  switch (Phase)
  {
    //... Teil entfernt

    case 2:
      SENSE_A;
      SENSE_RISING;
      COM_2;
      CommutationCounter++;
      if(compare_time(SenderWatchdog))
      {
        SenderWatchdog = calculate_time(625);
        sei();
        TOP_INT_ON;
      }
      Phase++;
      break;

    //... Teil entfernt
  }
}

Ich verstehe somit nicht, warum folgende Interrupt-Routine ausgeführt 
wird, der ausgelesene TCNT2-Wert sich aber unabhängig von OCR2A (schon 
völlig verschiedene Werte getestet) meistens bei ca 230 befindet. Meiner 
Meinung nach, sollte dieser ca. bei 254 liegen.

Was mir auch noch aufgefallen ist: der Interrupt erfolgt immer vor der 
ersten PWM-Wave. Will heissen: der  Interrupt wird bei Aktivierung 
sofort ausgeführt und wartet anscheinend nicht einmal bis zum ersten 
möglichen Compare-Match.

ISR(TIMER2_COMPA_vect)
{
  uint8_t data = TCNT2;
  u_transmit(data);
  PORTA ^= (1<<GREEN);
  TOP_INT_OFF;
}

Zu Testzwecken wird lässt dieser Interrupt einfach ein LED togglen und 
übermittelt den TCNT2-Wert per UART. Anschliessend schaltet er sich 
selbst ab, da er nur ca jede Sekunde erfolgen soll.

Vielen Dank

Gruss, AP

[Carsten R. (kaffeetante)]

Hallo Adrian,

es fehlt halt der Code und damit der vollständige Überblick wann die 
Interrupts wie maskiert werden. Sei es drum. Ich denke mir die 
Interrupts hinzu ohne diese Spekulation auch noch zu skizzieren. Dieses 
Konstrukt verursacht die Probleme wie folgt.

- Dir fehlt eine konsequente und sinnvolle Strategie für die 
Interruptmaskierung. Interrupts sollten während der 
Initialisierungsphasen möglichst deaktiviert sein.

- OCR2A wird nach dem Prescaler gesetzt. Dies verursacht den zusätlichen 
Compare-Match. Nach einem reset sind TCNT2 und OCR2A immer 0. Das 
setzten des Prescalers startet den Timer. 0=0 liefert den Compare-Match. 
Erst danach wird OCR2A auf 255 gesetzt. Setze den Prescaler erst zum 
Schluß der Initialisierung um den Timer erst dann zu starten.

- Deine ISR sind in C und völlig überladen. Das Interruptflag wird zwar 
bei TCNT2=255 gesetzt, aber bis Deine Routine beim Lesen von TCNT2 
ankommt sind einige Takte vergangen (Stichwort: Latenz) und der Timer 
hat schon wieder entsprechend weit heruntergezählt. Wenn dir 255-230 = 
25 Takte eine zu große Abweichung sind, müssen deine ISR inklusive 
Stackoperationen und Sprünge in weniger as 25 Takten erledigt werden 
können. Du kannst aber auch oder zusätzlich durch verändern von OCR2A 
die Latenz ausgleichen indem du den Interrupt dadurch vorziehst.

Zudem ist mangels Code nicht ersichtlich ob sichergestellt ist, daß das 
Compare-Match-Flag gelöscht ist unmittelbar bevor dieser Interrupt 
erlaubt wird. Das Flag könnte noch von einem vorerigen PWM-Impuls 
stehengeblieben sein, da die entsprechende ISR nicht bei jedem Match 
ausgeführt wird. Das fürt zu unvorersehbarem Verhalten.

Lösung: Halte die IS-Routinen so kurz wie möglich. Verwende 
(Inline)-Assembler wenn es zeitkritisch ist. Insbesondere die 
ISR(ANALOG_COMP_vect) ist zu aufgebläht.

Zum Beispiel: Warum wird TOP_INT_ON dort ausgeführt? Es ist nicht 
vorhersagbar wieviele Takte zwischen diesem Phasenwechsel und dem 
Comparematch liegen. Dazwischen (immerin 255 Takte) können sogar weitere 
Phasenwechsel liegen. Brushlessmotoren sind teilweise sehr hochtourig 
und es erfolgen mehrere Phasenwechsel pro Umdrehung. Die gewünschte 
Aktion erfolgt letztendlich synchron zur PWM und nicht zum 
Phasenwechsel. Bestenfalls läuft es pseudosynchron zum Phasenwechsel und 
keineswegs stabil synchron da drehzal- und lastabhängig.

Du hast dort eine Zeitberechnung (Watchdog, calculate_Time), wozu auch 
immer. Benutze den Zeitgeber um TOP_INT_ON einmal die Sekunde 
auszuführen oder lasse die ISR zu Compare-Match hochzählen bis 
PWM-Frequenz/256 um dann einmal eine Messung vorzunehmen.

Je nachdem was Du im Detail vorhast könnte es auch eine Option sein das 
PWM-Signal zu invertieren. Damit würden Overflow und Top die Plätze in 
der Mitte des High/Low-Pegels tauschen. Man müßte dann aber umdenken. 
255 wäre Minimum und 0 wäre Maximum. Das Singnal wäre dann im Verlauf 
das Gleiche aber Anfang und Ende und !!!Updateverhalten!!! wären etwas 
anders. Wenn das kein Probem darstellt oder wenn man dies 
berücksichtigen kann könnte man so den zweiten Timer sparen und den 
Overflow anstelle des fehlenden TOP-Signals verwenden.



Dies erst einmal zur Anregung

Viele Grüße
Carsten