Eine schönen guten Tag,
im Rahmen eines grösseren Projekts ist ein lästiger Fehler im
Zusammenhang mit dem ATMega 1284 aufgetreten. Ich konnte zur
Demonstration das Problem auf einen wirklich einfachen Code
runterbrechen, der mich ratlos zurück lässt.
Funktion: Das Programm soll lediglich PA4 schalten. Macht er aber nicht!
Zu Kontrolle schaltet das Programm nun auch noch den benachbarten Pin
und einen Weiteren auf einem anderen Port.
Um möglichst viele Fehlerquellen auszuschliessen, habe ich alle includes
vermieden und keine Optimierung verwendet. Wir haben es mit mehreren
1284 und einem 644 getestet. Sowohl mit Atmel Studio 5 als auch Atnmel
Studio 6 kompiliert. Auf zwei verschiedenen Boards ausprobiert. Mit
externem 12 MHz Quarz und auch interner Clock gestestet.
Immer das gleiche Ergebnis: PA4 tut nichts, während die anderen Pins
problemlos laufen.
Das kann doch nicht sein!
Rainer Z. schrieb:> Funktion: Das Programm soll lediglich PA4 schalten. Macht er aber nicht!>> Immer das gleiche Ergebnis: PA4 tut nichts, während die anderen Pins> problemlos laufen.
Ungefähr so gut wie: Geht nicht. Welches Potential liegt denn an PA4 an?
HW Fehler? Auf welchen Boards ausprobiert? Jumper vergessen zu ziehen?
etc.
Thomas Eckmann schrieb:> isidor schrieb:>> AVCC an VCC angeschlossen ?>> Kann man fast drauf wetten.
eher drauf wetten das nicht :-)
aber jeder der mal drauf reingefallen ist vergisst das nicht.
Joachim B. schrieb:> eher drauf wetten das nicht :-)
In Anbetracht dessen, wie oft das hier schon die Fehlerursache war, ist
diese Frage durchaus als Suggestivfrage anzusehen. Womit dann auch klar
sein sollte, worauf sich die Wette bezieht.
mfg.
Stefan Us schrieb:> Ersetze das deine defines mal durch
Warum? Das Programm läuft so, wie es oben gepostet wurde.
Stefan Us schrieb:> Es wird daher sehr viel schneller laufen, als du erwartest.
Natürlich. Aber die Optierungen wurden abgeschaltet. Und dann flackern
die Ports deutlich sichtbar vor sich hin.
mfg.
> Warum? Das Programm läuft so, wie es oben gepostet wurde.
Weil ich keinen Grund sehe, diese Definitionen selbst nochmal
hinzuschreiben. Dadurch wird das Fehlerrisiko unnötig erhöht. Wenn du
falsche Adressen hinschreibst, merkt der Compiler den Fehler nicht. Wenn
du aber aus versehen PORTÄ schreibst, merkt er es.
> Aber die Optierungen wurden abgeschaltet. Und dann flackern> die Ports deutlich sichtbar vor sich hin.
Du bist nicht Rainer Z. Er hat die Optimierungen vielleicht an gelassen.
Stefan Us schrieb:> Weil ich keinen Grund sehe, diese Definitionen selbst nochmal> hinzuschreiben. Dadurch wird das Fehlerrisiko unnötig erhöht. Wenn du> falsche Adressen hinschreibst, merkt der Compiler den Fehler nicht. Wenn> du aber aus versehen PORTÄ schreibst, merkt er es.
Und was hilft das jetzt bei der Fehlersuche?
Das Programm läuft, so wie es gepostet wurde. Nur nicht auf seiner
Hardware. Wozu soll er dann die Software ändern? Die wird auf seiner
Hardware dann auch nicht laufen.
mfg.
> PA4 tut nichts, während die anderen Pins problemlos laufen.> AVCC an VCC angeschlossen ?
Wenn das die Problemursache wäre, dann würde IMHO PA3 auch nicht
funktionieren.
> Das Programm läuft, so wie es gepostet wurde.> Nur nicht auf seiner Hardware.
Ich fürchte, dass es auch auf seiner Hardware läuft - er denkt nur es
würde nicht laufen, weil das Timing Verhalten ganz anders ist, als
erwartet.
@Rainer Z.
> PA4 tut nichts
Wie genau kommst du zu dieser Aussage?
Stefan Us schrieb:> Wenn das die Problemursache wäre, dann würde IMHO PA3 auch nicht> funktionieren.
Wenn der Port A durch zusätzliche Beschaltung eine "schleichende
Versorgungsspannung" bekommt kann es zu solchen Effekten kommen.
Mir ist noch etwas eingefallen:
> Was kann den hier noch schief laufen ?
Vielleicht hast den Compiler mit dem falschen CPU Typ aufgerufen
-mmcu=atmega1284p
so .....
... wen hier jetzt tote Hose ist dann hat sich entweder der Thread-
Ersteller in den Tod gestürzt .....
..... oder ATmega 1284P geht jetzt nicht nicht.
Stefan Us schrieb:> Ich fürchte, dass es auch auf seiner Hardware läuft - er denkt nur es> würde nicht laufen, weil das Timing Verhalten ganz anders ist, als> erwartet.
Egal, was er erwartet, PA3 tut, PA4 nicht.
Oliver
Hallo zusammen,
erst mal vielen Dank für die zahlreichen Versuche mir zu helfen!
Ich werde mal versuchen in diesem Text auf alle Mails gesammelt zu
antworten:
> Was hängt denn an dem Pin dran?LED über Vorwiderstand gegen Masse.
> AVCC an VCC angeschlossen ?> Kann man fast drauf wetten.
Besser nicht wetten, ist angeschlossen. Sogar wie von Atmel
vorgeschlagen mit Tiefpassfilter. Das würde aber auch nicht erklären,
warum nur PA4 nicht geht. PA0-PA3 und PA5-PA7 funktionieren hingegen
tadellos. Sowohl als Ausgang als auch als digitaler Eingang und auch als
analoger Eingang.
PA4 ist aber eine "taube" Nuss: als Output liefert er immer nur 0, als
Eingang erratische Werte.
>@Rainer Z.>> PA4 tut nichts> Wie genau kommst du zu dieser Aussage?
Messung mit Multimeter und Logikanalysator.
> Ungefähr so gut wie: Geht nicht. Welches Potential liegt denn an PA4 an?> HW Fehler? Auf welchen Boards ausprobiert? Jumper vergessen zu ziehen?> etc.
Das eigentliche Modul verwendet serielle Kommuniktion zu einem AVR32,
PWM-Ausgabe, Mehrkanal DACs über SPI, verschiedene Schalter, acht Potis,
3 LEDs, etc.
Wie gesagt: nur (!) PA4 geht nicht, alles andere läuft ohne Probleme.
Um dem Fehler auf die Spur zu kommen, haben wir letzlich den einfachst
möglichen Aufbau auf einer Lochrasterplatine verwendet (nur
Stromversorgung, Quartz, LED mit Vorwiderstand). Alle Pins gehen, aber
PA4 eben nicht. Ich kann aber auch in den Datenblättern nicht erkennen,
dass PA4 im Vergleich zu z.B. PA3 irgendeine "Sonderbehandlung"
bräuchte.
Ausprobiert wurde dieser Code mit 1284 im DIP-Gehäuse, 1284 als
SMD-Variante und auf einem 644er DIP-Gehäuse um Bauteilefehler
auszuschliessen.
> Ersetze das deine defines mal durch> #include <io.h>> Bei normalen Einstellung wird der Compiler solche Zeilen vollständig weg> optimieren:> [..]> Es wird daher sehr viel schneller laufen, als du erwartest.
Der Compiler wurde entsprechend dem Prozessortyp eingestellt. Alle
Optimierungen sind abgeschaltet. Compiliert wurde auf drei (!)
verschiedenen Rechnern mit Atmel Studio 5 und Atmel Studio 6.
Ich habe mit Absicht alle Includes vermieden, um den gesamten Code in
einer Datei zu haben. Selbstverständlich würde ich zum Warten nie eine
verschachtelte for-schleife nutzen und verwende auch ansonsten die
üblichen Include-Dateien. ;-/
Aber Timerinterrupts und GCC "delay"-Routinen sind zusätzlicher
verdeckter oder möglicherweise fehlerhafter Code! Ich hänge mal die
Disassemblerausgabe dran. Daran kann man sehen, was tatsächlich in den
Prozessor geschoben wird. Ich kann da keinen Fehler sehen.
Bis Dann
Rainer
Ein bekannter von mir präsentierte neulich Arduino Clones, bei denen
einzelne Pins nicht beschaltet (aber beschriftet) waren. Das würde zu
deinem Fehlerbild passen.
> PA4 ist aber eine "taube" Nuss: als Output liefert er immer> nur 0, als Eingang erratische Werte.
>PA4 ist aber eine "taube" Nuss: als Output liefert er immer nur 0, als>Eingang erratische Werte.
Dann liegt die Vermutung nahe das der Pin gar nicht angeschlossen ist.
Prinzipiell braucht PA4 keine Sonderbehandlung. Der muß genauso
funktionieren wie PA3.
Wenn alle eure Prozessoren das selbe Fehlerbild zeigen (644er wie
1284er), macht ihr irgend etwas grundlegend falsch, oder eure Schaltung
zerstört den Pin.
Rainer Z. schrieb:> zusätzlicher> verdeckter oder möglicherweise fehlerhafter Code! Ich hänge mal die> Disassemblerausgabe dran.
Zitat:
> Hello_1280.elf:
Hm. Warum nicht Hello_1284P ?
Welche Compiler- und avrlibc-Version hat den Code erzeugt?
Oliver
Am Code liegt es nicht. Mit Studio 4 übersetzt und in einen 1284p
gegossen läuft es prima und die LEDs an PA3 und PA4 blinken.
Deine Hardware hat eine Macke.
Hallo,
holger schrieb:>>PA4 ist aber eine "taube" Nuss: als Output liefert er immer nur 0, als>>Eingang erratische Werte.>> Dann liegt die Vermutung nahe das der Pin gar nicht angeschlossen ist.
Das war es dann auch!
Zur Erläuterung: die Hardware steht grösstenteils nicht mal in der
gleichen Stadt, deshalb sind meine Antworten immer mit Verzögerungen
durch Telefonierei verbunden.
Unglücklicherweise war sowohl auf der SMD-Platine als auch auf der
Lochrasterplatine ausgerechnet PA4 tatsächlich nicht sauber verlötet!
Mann, bin ich froh, dass ich nicht für die Hardware verantwortlich
zeichne, sondern nur die Software mache. ;-/
Jetzt geht auch meine ursprüngliche "grosse" Software ohne Probleme.
Noch mal vielen Dank für die vielen Bemühungen. Manchmal werden die
einfachsten Dinge übersehen ...
Thread kann geschlossen werden!
Bis Dann
Rainer
Rainer Z. schrieb:> Zur Erläuterung: die Hardware steht grösstenteils nicht mal in der> gleichen Stadt, deshalb sind meine Antworten immer mit Verzögerungen> durch Telefonierei verbunden.
Sorry, aber in diesem Zusammenhang kommt bei mir wieder die
Erinnerung an den Begriff Salamitaktik auf.
Wenn jemand hier im Forum behauptet dass an einem Portpin kein
Signal kommt dann darf man annehmen dass er das selbst gemessen
hat. Hat er aber wohl nicht, sondern ein anderer Mensch der in
die Fehleranalyse nicht einbezogen werden konnte da als
potentielle Fehlerquelle nicht bekannt.
Rainer Z. schrieb:> Wir haben es mit mehreren> 1284 und einem 644 getestet.Rainer Z. schrieb:> Unglücklicherweise war sowohl auf der SMD-Platine als auch auf der> Lochrasterplatine ausgerechnet PA4 tatsächlich nicht sauber verlötet!
Irgendwie kommt kann ich mir da ein "Ja nee, is klar" nicht verkneifen.
Oder im Klartext: glaubst du doch selber nicht.
Oliver
Hallo,
isidor schrieb:> Rainer Z. schrieb:>> Zur Erläuterung: die Hardware steht grösstenteils nicht mal in der>> gleichen Stadt, deshalb sind meine Antworten immer mit Verzögerungen>> durch Telefonierei verbunden.>> Sorry, aber in diesem Zusammenhang kommt bei mir wieder die> Erinnerung an den Begriff Salamitaktik auf.>> Wenn jemand hier im Forum behauptet dass an einem Portpin kein> Signal kommt dann darf man annehmen dass er das selbst gemessen> hat. Hat er aber wohl nicht, sondern ein anderer Mensch der in> die Fehleranalyse nicht einbezogen werden konnte da als> potentielle Fehlerquelle nicht bekannt.
Nein, so ist es nicht! Ich habe tatsächlich selbst gemessen aber eben
nur an einer (!) von mehreren Hardwareaufbauten. Bei meinem Aufbau habe
ich extra eine Stiftleiste um Messgeräte besser anschliessen zu können.
Ich bin in der Tat davon ausgegangen, dass dieser Aufbau vorab auch nach
der Herstellung ausreichend geprüft worden war.
Das war eine falsche Annahme.
Tut mir leid, wenn da ein falscher Eindruck enstanden ist. Ich mag
Salami aber nicht in taktischer Hinsicht.
Bis Dann
Rainer
Hallo,
Oliver S. schrieb:> Rainer Z. schrieb:>> Wir haben es mit mehreren>> 1284 und einem 644 getestet.>> Rainer Z. schrieb:>> Unglücklicherweise war sowohl auf der SMD-Platine als auch auf der>> Lochrasterplatine ausgerechnet PA4 tatsächlich nicht sauber verlötet!>> Irgendwie kommt kann ich mir da ein "Ja nee, is klar" nicht verkneifen.> Oder im Klartext: glaubst du doch selber nicht.
Kann ich auch kaum glauben, ist aber trotzdem so passiert. Wie gesagt
ich kümmere mich nur um die Software. Hardware ist nicht meine
Baustelle, die bekomme ich angeliefert.
Bis Dann
Rainer
Rainer Z. schrieb:> Unglücklicherweise war sowohl auf der SMD-Platine als auch auf der> Lochrasterplatine ausgerechnet PA4 tatsächlich nicht sauber verlötet!
Seltsam. Das erste, das wirklich erste was ich mache (und wahrscheinlich
jeder andere ebenso) wenn bei einem Prototypen der gerade eben erst das
Licht des Lötofens erblickt hat irgendwo am anderen Ende der Platine
etwas das durch einen Portpin gesteuert werden soll augenscheinlich
nicht das tut was es soll ist:
** Ich messe an besagtem Pin **
ob da auch rauskommt was ich beabsichtige dort rauszugeben. Und wenn ich
das nicht gemacht habe und stattdessen nur 5 Meter entfernt am anderen
Ende der noch völlig ungetesteten Platine gemessen habe und nicht am Pin
selbst dann komm ich (und auch kein anderer hier) nie im Leben auch nur
ansatzweise auf die Idee zu vermuten der Portpin selbst würde nicht
schalten und ich käme schon gar nicht auf die Idee umständlich einen
Aufbau mit Lochraster zu machen (um dann dort ebenfalls zu versäumen
eine Messung vorzunehmen) oder gar im Forum zu posten der Pin ginge
nicht bevor ich nicht direkt
** am Pin gemessen habe **
um festzustellen dass tatsächlich der Pin die Ursache ist.
