AVR-Studio Bugs

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Einleitung

Das kostenlose AVR Studio von Atmel enthält einige Fehler. In der Hilfe zu AVR Studio 4.13 build 528 (Menü Help -> AVR Tools Users Guide -> AVR Studio -> Introduction -> Known Issues -> Simulator) gibt es eine Zusammenstellung der bekannten Unzulänglichkeiten der Simulation. Falls euch zusätzliche Fehler bekannt sind, bitte hier hinzufügen.

Damit Fehler in einer der kommenden Versionen (hoffentlich) behoben werden, sollten Fehlerberichte ("Bug-Reports") zur jeweils aktuellen Version mit genauer Beschreibung zum Reproduzieren des Fehlers (evtl. mit Codebeispiel) auch an avr@atmel.com gesendet werden (in Englisch).

Das AVR-Studio-Forum bei avrfreaks wird ebenfalls von den AVR-Studio-Entwicklern "beobachtet". Gelegentlich finden sich inoffizielle Updates für AVR-Studio auf www.atmel.no/beta_ware.

Problem: AVR-Studio-Installation nicht möglich "Setup.exe hat ein Problem festgestellt und muss beeendet werden." Workaround: Wie im englischsprachigen Forum avrfreaks.net bereits analysiert wurde, ist das heruntergeladene Installationsprogramm fehlerhaft. Das Problem tritt nicht auf, wenn man den Internet-Explorer zum herunterladen verwendet - so traurig das auch ist. Die Datei ist dann ein Byte kleiner und funktioniert.

AVR-Studio 4.18, evtl. auch frühere

Installation

Wenn es auf XP und der Nutzung des Dienstes Alice Smartdisk passiert, dass das AVR-Studio-Installationsprogramm kurz nach dem konfigurieren der Pfade stehenbleibt, ist womöglich ein zur Smartdisk-Software gehörender im Hintergrund laufender Dienst "humyo.com" bzw. hrfscore.exe der Verursacher. Das Beenden des Dienstes per Taskmanager schafft dann Abhilfe.

AVRStudio (sowie auf die von Atmel bereitgestellte AVR-gcc-Toolchain) installieren sich standardmäßig nach C:\Program Files, korrekt wäre es aber, die globale Umgebungsvariable %PROGRAMFILES% zu benutzen, die von Windows zum korrekten Pfad expandiert wird. Dieser Fehler fällt unter Windows XP auf, unter Windows 7 nicht, da Microsoft dort auf links auf Verzeichnisse ermöglicht und "C:\Program Files" auf den lokalisierten Verzeichnisnamen zeigt, sicherlich genau um solch unsauber geschriebene Installer zu zwingen, in den korrekten Pfad zu installieren.

Der Installer-Pfad-Bug (und weitere Bugs) in Englisch, so wie von mir heute auch an Atmel gesendet (Übersetzung darf machen wer mag, vielleicht habe auch ich demnächst Zeit dafür, bei Edit bitte nicht alles wegwerfen, diese Hinweis-Zeile darf/muss aber langfristig natürlich etnfernt werden):

A) Installer (least important to be fixed):

A.1) -installs to hard-coded "C:\Program Files\" instead of using the environment variable %PROGRAMFILES% which would be expanded by Windows to the correct path. (On a Windows OS localized to german %PROGRAMFILES% expands to "C:\Programme\") Bugfix ist fairly easy: just replace every occurance of "C:\Program Files" by %PROGRAMFILES% This bug is also valid for the AVR-gcc-Toolchain installer and other AVRStudio add-ons. But will occur on Windows 200 and XP, Windows 7 hast a new directory-Link feature and has a hard-coded "C:\Program Files\" linked to the correct localized path. (This detailed explanation is because I already reported this bug 1 or 2 years ago and the answer was this wouldn't be a bug...)

IDE-Fenster

B) Main IDE Window:

B.1) -If files are opened or closed, this is only saved to project file if project options have been opened and comfirmed with OK-Button (then IDE will ask if changes to project should be saved). (This is not ot really a bug, but at least if you have closed 50 or more Tabs/Windows an then close the IDE you would not expect to have all windows open again if IDE is started the next time...)

B.2) -If project files are renamed, the IDE sometimes gets confused (Work-Araound: close & re-open the IDE)

B.3) -If files are added to project the IDE seems sometimes not to keep track of that (Work-Araound: close & re-open the IDE)

B.4) -setup of programmer window is not saved in project file (programmer window should have a button "SAVE setting to project file", this prevents saving fuse bits to project that have been read but are not wanted to be saved to project)

B.5) -some fields (e.g. output directory, at least if set to a relative path) do not support CTRL+C / CTRL+V / CTRL+X, but using the right-button context menu for cut&paste works

B.6) -sometimes Windows XP kicks AVRStudio.exe during it is closed. This happens not very often and mostly if many (20 to 60) sub windows (opened proect files) have been in use and it has no negative effect, all files are always saved BEFORE this crash (happens roughly each 30th to 100th exit of AVRStudio)

Programmer-Fenster (innerhalb der IDE)

C) Programmer Window (inside IDE):

C.1) -MCU type, fuse- and lock-bits, file paths, etc. in programming window are GLOBAL to all projects :-(, but should be PROJECT-SPECIFIC, of course ("Work-Around": remember or note correct fuse setting, use a relative file path, e.g. .\default\ and always same elf name in project option, e.g. main.elf, resulting in having always .\default\main.hex and .\default\main.eep so this hasn't to be adjusted for each and every project)

C.2) -In the programmer Window (at least if using AVR ISP mkII) file path can reproduceable be messed up: I always have set the paths for FLASH and EEPROM files to .\default\main.hex and .\default\main.eep but if I read them back (and am requested to select a path), the next time I write a file to the MCU, it is not taken any longer from path .\default\main.* relative to project dir, but relative to the path where I read the MCU file to (programming the wrong file to the MCU) (e.g.: i have a file c:\tmp\default\main.hex and saved the data read from MCU to c:\tmp\ then next time you flash it is taken from c:\tmp\default\main.hex (since the relative path is concatenated now to the location a file was last time written to instead concatenated to project path) ) Even worse: even reading the EEPROM also messes not only the path to the EEPROM file I'd expect to be used, it also messes up the path to the FLASH-file! (Work-Around: close & re-open the IDE)

C.3) -If reading back from a MCU, the initial path shown if "Read" button is clicked is always the last one used (not really a bug, but nasty since this path is not project-specifc)

C.4) -Cut&Paste by keyboard (CTRL+C / CTRL+V / CTRL+X) does not work for any text fields, but using the right-button context menu for cut&paste works

AVR-Studio 4.12 RC1 (Build 450) und später

Simulation der 16-Bit Timer

AVRSimIOTimert16pwm1.DLL File Version: 1.0.0.10 Product Version: 1.0.0.2

Diese DLL wird zur Simulation der 16-Bit Timer in ATmega8/88/48/32 verwendet (wahrscheinlich in allen CPU's mit zwei Output Compare Units).

Der Fehler tritt im ATmega128 nicht auf, der einen erweiterten 16-Bit Timer hat und deswegen die AVRSimIOTimert16pwm2.DLL verwendet.

Fehler: 

Mode  Timer/CounterMode                Fehlerbeschreibung
      of Operation
0     Normal                           kein Fehler
1     PWM, Phase Correct, 8-bit        kein Fehler
2     PWM, Phase Correct, 9-bit        kein Fehler
3     PWM, Phase Correct, 10-bit       kein Fehler
4     CTC                              kein Fehler
5     Fast PWM, 8-bit                  arbeitet wie Mode 1
6     Fast PWM, 9-bit                  arbeitet wie Mode 2
7     Fast PWM, 10-bit                 arbeitet wie Mode 3
8     PWM, Phase and Frequency Correct ignoriert ICR1, arbeitet wie Mode 0
9     PWM, Phase and Frequency Correct ignoriert OCR1A, arbeitet wie Mode 1
10    PWM, Phase Correct               ignoriert ICR1, arbeitet wie Mode 2
11    PWM, Phase Correct               ignoriert OCR1A, arbeitet wie Mode 3
12    CTC                              ignoriert ICR1, arbeitet wie Mode 4(OCR1A)
13    (Reserved)
14    Fast PWM                         ignoriert OCR1A, arbeitet wie Mode 2
15    Fast PWM                         ignoriert ICR1, arbeitet wie Mode 3

Ursache:

WGM13 wird total ignoriert und WGM12 nur für die Aktivierung von Mode 4 verwendet. Das ist kein einfacher Programmierfehler, der Rest ist unbegreiflicherweise gar nicht implementiert! Auch AVRStudio 4.17 Build 666 immer noch falsch.

weitere Fehler:

  • 1. OCF1B: Wenn OCR1B = 0 ist, wird das OCF1B-Flag bei TCNT = 0 nicht gesetzt und der Interrupt somit nicht ausgeführt.
  • 2. OCR1B PRIO: Wenn OCR1A = OCR1B ist, wird manchmal der OCR1B-Interrupt vor dem OCR1A-Interrupt ausgeführt obwohl OCR1A die höhere Priorität hat.
  • 3. TCNT1 Wrap: Das temporäre Register für die Zugriffe auf die 16-Bit Register des Timers wird nicht simuliert. Folge sind die üblichen Wraparound-Effekte, wie sie am realen AVR nur entstehen, wenn man nicht die korrekte Zugriffsreihenfolge auf L- und H-Teil des Registers einhält. (siehe z. B. Datenblatt ATMega16, S. 92 ff.) Verifiziert mit Studio-Version 4.13.528 bei der Simulation von ATMega16 und ATMega32. Verifiziert mit Studio-Version 4.15.623 bei der Simulation von ATMega32.

ATmega88

  • Schreiben nach UCSR0C (Adresse 0xC2h) beschreibt ebenfalls UBRR0H (Adresse 0xC5h)


ATtiny2313 und ATtiny13

  • Schreiben nach OCR0A/B wird im Single Step nicht angezeigt (nicht übernommen?!). Erst nach einem Run wird die Änderung angezeigt.

AVR-Studio 4.10 (Build 356)

ATMega8

  • Simulator (AD Wandler). Beim manuellen Setzen des ADIF Bits in ADCSR, wird nicht die dazugehörige Interrupt Routine angesprungen. <--- Kein Bug, eher Programmierfehler: Interrupt-Flags lassen sich nicht per Software setzen, sie lassen sich nur löschen und zwar indem man sie setzt (!)

AVR-Studio 4.09 (Build 338)

AVR Studio :4, 9,0, 338 Platform :JTAG ICE Build :1, 0, 0, 32 Part :ATmega16 Build :91

  • 1. Beim Debuggen mit JTAG, wenn globale Struktur ohne typedef deklariert ist und Deklaration im Header-datei steht, zeigt AVR-Studio im Watch-fenster nicht.
  • 2. Variable foo mit __attribute__ ((section (".eeprom"))) wird mit SRAM-location angezeigt, obwohl richtig behandelt.

AVR-Studio 4.08 (Build 310)

ATtiny12

  • Int0 (Interrupt 0) wird durch PinB.2 (falsch) und nicht durch PinB.1 (richtig) ausgelöst (In Version 4.09 bereinigt)

ATtiny15

  • OCF1A-Flag in TIFR wird beim Ausführen des Interrupts nicht automatisch zurückgesetzt. Das führt dazu, dass die Interruptroutine sofort nach Beendigung wieder angesprungen wird obwohl inzwischen kein neuer Interrupt erfolgte. Abhilfe: Zurücksetzen des Flags per Programm in der Interrupt-Routine:
ldi temp, 0x40
out TIFR, temp
  • PINB.1 zeigt Signalwechsel obwohl laut DDRB.1 als Eingang programmiert. Festgestellt bei Verwendung der "output compare"-Funktion von Timer/Counter1.

AT902313 (und wahrscheinlich auch andere Devices)

Die Simulation des EEPROM-Beschreibens funktioniert nicht. Der Code scheint zwar fehlerfrei zu laufen, doch die Daten im EEPROM verändern sich nach dem Schreibbefehl einfach nicht.

Simulator (getestet mit AT90S8535)

Wird gerade im Einzelschritt Modus (F11) ein C Code mit einer if Verzweigung simuliert und in diesem Moment die Variable, die für die if Verzweigung entscheidend ist, von Hand geändert und dann der nächste Schritt simuliert, stürzt das AVR Studio mit der Meldung "Diese Anwendung wird aufgrund eines ungültigen Vorgangs geschlossen" ab.

Beispiel: if (dispmode == 2) {

Der gelbe Pfeil zeigt auf die Zeile; dispmode (vom Typ uint8_t) ist Null; dispmode wird zur "Watch 1" Liste hinzugefügt und dort wird die Variable von Hand in 2 geändert; dann wird der nächste Schritt (F11) simuliert -> Absturz des Programms

Timer des ATMEGAS128 wird nicht richtig simuliert

Es ist leider schon eine Ewigkeit aus, deshalb kann ich keine genaueren Angaben machen. Es gibt einen Modus, wo der Timer hinaufzählt. Hat er den höchsten Wert erreicht zählt er wieder hinunter. Im AVR-Studio änderte der Timer nie seine Zählrichtung.

Abgerufen von „https://www.mikrocontroller.net/index.php?title=AVR-Studio_Bugs&oldid=75785“