mikrocontroller.net

Forum: Compiler & IDEs Spuk oder Programmfehler?


Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

das nachfolgende Programm funktioniert nur eingeschränkt:
#include <avr/io.h>           
#include <util/delay.h>  

int main(void)
{
   DDRA = 0xFF;
   while (1)
   {
  PORTA =0xFF;       
  _delay_ms(1000);
  PORTA =0x00;
  _delay_ms(1000);  
  };
}
Ich hatte erwartet, daß der Port A jeweils eine Sekunde high oder low 
ist, was aber keineswegs geschieht. Vielmehr ist eine Kontroll-LED fast 
immer hell und geht im Sekundentakt nur ganz kurz aus.

Wenn ich aber
- die beiden PORTA-Zeilen vertausche
o d e r
- die untere delay-Zeile an den Beginn der while-Schleife verschiebe,
dann blinkt es es erwartungsgemäß.

Hat jemand eine Erklärung für dieses eigenartige Verhalten?

Gruß
Egon

Autor: Richard B. (rbrose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck dir mal die delay.h an.

Da steht sowas drin:

  The maximal possible delay is 262.14 ms / F_CPU in MHz.


ich vermute das ist das Problem.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schalte den Watchdog ab.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard B. schrieb:
> Guck dir mal die delay.h an.
>
> Da steht sowas drin:
>
>   The maximal possible delay is 262.14 ms / F_CPU in MHz.
>
>
> ich vermute das ist das Problem.

Bei der neuesten WinAVR Version geht das aber.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard B. schrieb:
> Guck dir mal die delay.h an.
>
> Da steht sowas drin:
>
>   The maximal possible delay is 262.14 ms / F_CPU in MHz.
>
>
> ich vermute das ist das Problem.

Ja, vorallem steht da drin:
>> The maximal possible delay is 262.14 ms / F_CPU in MHz.
>>
>> When the user request delay which exceed the maximum possible one,
>> _delay_ms() provides a decreased resolution functionality. In this
>> mode _delay_ms() will work with a resolution of 1/10 ms, providing
>> delays up to 6.5535 seconds (independent from CPU frequency).

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richard B. schrieb:
> Guck dir mal die delay.h an.
>
> Da steht sowas drin:
>
>   The maximal possible delay is 262.14 ms / F_CPU in MHz.
>
>
> ich vermute das ist das Problem.


Leider nicht, denn
1. bisher habe ich an anderer Stelle mit z.B. 5000 ms keine Probleme
   gehabt (vielleicht neuere  WinAVR-Version)?
2. ich habe probeweise die Zeile delay_ms(1000) ersetzt durch fünf mal
   hintereinander delay_ms(1000) - gleicher Effekt.

@Holger
Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das 
ganze Programm). Außerdem mußte er ja auch ansprechen, wenn ich, wie 
beschrieben, die PORT-A-Zeilen vertausche.

mfg
Egon

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon Müller schrieb:

> Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das
> ganze Programm).

Den kann man auch per Fuse einschalten.

> Außerdem mußte er ja auch ansprechen, wenn ich, wie
> beschrieben, die PORT-A-Zeilen vertausche.

Ja. Aber das kann dennoch zu Blinkeffekten führen.

Gib mal statt 0x00/FF einen Zähler ab 1 aufwärts auf die LEDs. Dann 
siehst du, ob der auch zählt oder immer startet und deshalb 1 kommt.

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Egon Müller schrieb:
>
>> Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das
>> ganze Programm).
>
> Den kann man auch per Fuse einschalten.

WDTON ist aus
>
>> Außerdem mußte er ja auch ansprechen, wenn ich, wie
>> beschrieben, die PORT-A-Zeilen vertausche.
>
> Ja. Aber das kann dennoch zu Blinkeffekten führen.
>
> Gib mal statt 0x00/FF einen Zähler ab 1 aufwärts auf die LEDs. Dann
> siehst du, ob der auch zählt oder immer startet und deshalb 1 kommt.

Ja, er zählt hoch.

Sehr eigenartig: der häßliche Effekt tritt auf, wenn ich in der ersten 
PORT-A-Zeile schreibe PORTA = 0xFF  (oder =255). Schreibe ich PORTA = 
254 (oder weniger), ist alles in Ordnung.
Der Zusammenhang zwischen dem Port und dem nachfolgenden Delay ist mir 
unerklärlich

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann käme noch die Hardware in Frage. Kerkos vergessen, AVCC nicht 
angeschlossen, ...

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist der oben zitierte Code 
(Beitrag "Spuk oder Programmfehler?") auch wirklich 
GENAU DER CODE, welcher SO nicht funktioniert, oder hast du deinen Code 
nur für dein Posting zusammgengestutzt, ohne diesen nochmals separat zu 
testen?

Welchen Controller verwendest du? Evtl. könnten wir den Code dann mal 
bei uns auf nem Controller testen....

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magnus Müller schrieb:
> Ist der oben zitierte Code
> (Beitrag "Spuk oder Programmfehler?") auch wirklich
> GENAU DER CODE, welcher SO nicht funktioniert, oder hast du deinen Code
> nur für dein Posting zusammgengestutzt, ohne diesen nochmals separat zu
> testen?
>
> Welchen Controller verwendest du? Evtl. könnten wir den Code dann mal
> bei uns auf nem Controller testen....

Das ist der ganze Code,
der Controller ist ein Atmega 644P mit 16-MHz-Quarz,
benutzt wird WinAVR090313.

Der Code dient dazu, bunte Adern, die über mehrere Stecker laufen, auf 
ihre Zuordnung zu den Ports nochmals sicherheitshalber zu kontrollieren. 
Das ist zwar inzwischen geklärt, aber nun würde ich gern den zufällig 
entdeckten Effekt verstehen.

mfg
Egon

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Dann käme noch die Hardware in Frage. Kerkos vergessen, AVCC nicht
> angeschlossen, ...

Die Hardware ist vielfach kontrolliert und getestet (nicht von mir!), es 
handelt sich um Uli Radigs Webserver, auf dem derzeit dieses 
Miniaturprogramm betrieben wird, um eine zusätzliche Platine zu 
integrieren.

Ich gehe mal davon aus, daß Ulis Webmodul in Ordnung ist und auf meiner 
Platine gibt es nur einige Stecker und eine LED samt Vorwiderstand. 
Daran dürfte es nicht liegen.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das ist der ganze Code,

Poste dein Projektverzeichnis als ZIP Archiv.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon Müller schrieb:

> Die Hardware ist vielfach kontrolliert und getestet (nicht von mir!), es
> handelt sich um Uli Radigs Webserver

Falls es die Platine von mikrocontroller.com sein sollte: Just bei der 
fehlen die Kerkos zwischen (A)VCC und GND.

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Egon Müller schrieb:
>
>> Die Hardware ist vielfach kontrolliert und getestet (nicht von mir!), es
>> handelt sich um Uli Radigs Webserver
>
> Falls es die Platine von mikrocontroller.com sein sollte: Just bei der
> fehlen die Kerkos zwischen (A)VCC und GND.

Ist nicht von mikrokontroller.com, sondern von Ulrich Radig und das ist 
am AVR und den übrigen IC's mit etlichen 100-nF-Kondensatoren bestückt
http://ulrichradig.de/ unter ETH_M32_EX.

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
>>Das ist der ganze Code,
>
> Poste dein Projektverzeichnis als ZIP Archiv.

Für dieses Miniatur- und Hilfsprogramm gibt es kein Projekt, ich 
kompiliere es innerhalb von pn2 und schicke es manchmal mit AVRStudio 
oder direkt aus pn2 zum Controller. Ein Makefile könnte ich noch bieten 
und ein Hexfile, meinst Du das? Sonst existiert nichts weiter.

Gruß
Egon

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtige MCU im Makefile angegeben?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pullup am Reset?

Poste auch mal den Compileroutput. Warnings?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ein Makefile könnte ich noch bieten
>und ein Hexfile, meinst Du das? Sonst existiert nichts weiter.

Poste mal den kompletten Ordner, in dem das Source-File und das makefile 
stecken, am einfachsten zusammengezippt.

Oliver

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon Müller schrieb:
> A. K. schrieb:
>> Egon Müller schrieb:
>>
>>> Ein Watchdog ist nicht eingeschaltet (was ich gepostet hatte, ist das
>>> ganze Programm).
>>
>> Den kann man auch per Fuse einschalten.
>
> WDTON ist aus
Könntest du bitte genau formulieren, welchen Zustand WDTON gerade hat? 
Ich weiß, klingt blöde, aber das ist bei den Fuses ja immer noch zehnmal 
umgedreht :-)

Autor: Egon Müller (kpc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
>>Ein Makefile könnte ich noch bieten
>>und ein Hexfile, meinst Du das? Sonst existiert nichts weiter.
>
> Poste mal den kompletten Ordner, in dem das Source-File und das makefile
> stecken, am einfachsten zusammengezippt.
>
> Oliver

Hier mein allererster Versuch, ein zip-Archiv zu erstellen, hoffentlich 
ist er gelungen.

@Sven
in AVRStudio ist bei den Fuses  k e i n  Häkchen bei WDTON gesetzt.

Gruß
Egon

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hier mein allererster Versuch, ein zip-Archiv zu erstellen, hoffentlich
>ist er gelungen.

Perfekt.

Kannts du jetzt noch den Ordner mirtPORTA=255; also der Version, die 
anscheinend nicht funktioniert, hier einstellen?

Oliver

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
>>Hier mein allererster Versuch, ein zip-Archiv zu erstellen, hoffentlich
>>ist er gelungen.
>
> Perfekt.
>
> Kannts du jetzt noch den Ordner mirtPORTA=255; also der Version, die
> anscheinend nicht funktioniert, hier einstellen?
>
> Oliver

Es  i s t  der Ordner (umbenannt, weil ich die übrigen Exercitien 
separat weiterführen möchte).

Die im zip-Archiv enthaltene Version Porttest.c ist die eigenartige 
Version:
schreibe ich bei PORTA = 254, blinkt es erwartungsgemäß,
schreibe ich  = 0xFF oder = 255, dann geht es bei mir schief.

Vielleicht sollte ich noch hinzufügen:
Wenn ich in der mißlungenen Schreibweise (PORTA = 0xFF) die unterste 
Delayzeile ganz nach oben verschiebe, dann ist es wieder so, wie man es 
sich wünscht.

mfg
Egon

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>schreibe ich  = 0xFF oder = 255, dann geht es bei mir schief.

Eben. Genau diese Version von deinem Computer, mit deinem Compiler 
compiliert, hätte ich gerne (denn, wenn ich das bei mir kompiliere, 
funktionieren beide Varianten. Garantiert).

Oliver

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es reicht auch, wenn Du das "255", nicht funktionierende Hex File 
reinstellst.

Das wäre schon interessant was da an anderem Code erzeugt wird, zuletzt 
eingestellter Code mit "254" ist jedenfalls einwandfrei, nachfolgend 
übersetzt:
LDI    R20,0xFE       //port value
LDI    R18,0x90       //preload for delay
LDI    R19,0x01       //same
OUT    0x02,R20       //set port

LDI    R24,0x10       //delay
LDI    R25,0x27       
MOVW   R30,R18   
SBIW   R30,0x01    
BRNE   PC-0x01     
SBIW   R24,0x01    
BRNE   PC-0x04     

OUT    0x02,R1        //clear port, R1 is cleared

LDI    R24,0x10       //delay
LDI    R25,0x27       
MOVW   R30,R18   
SBIW   R30,0x01    
BRNE   PC-0x01
SBIW   R24,0x01    
BRNE   PC-0x04

RJMP   PC-0x0010     //loop

Autor: Egon Müller (kpc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein neuer Versuch:
nicht funktionierende Version Porttest.c (mit PORTA = 255), kompiliert 
mit WinAVR 090313;
dazu alle erzeugten Dateien (incl. Hex-Datei) und außerdem
die im Unterverzeichnis .dep angelegte Datei (umbenannt in 
dep.Porttest.o.d).

Das Ganze als zip-Datei hier angehängt.

mfg
Egon

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die beiden Hex-Files unterscheiden sich nur in dem Wert, der in
PORTA geschrieben wird:
< :100090000C9400008FEF81B94EEF20E931E042B9B6
                            ^ ^                -> 0xFE = 254
---
> :100090000C9400008FEF81B94FEF20E931E042B9B5
                            ^ ^                -> 0xFF = 255

Das kann also kaum die Ursache für das unterschiedliche Timing bei der
Ausführung sein, es sei denn, es liegt ein Hardwarefehler im Controller
oder der umliegenden Schaltung vor. Hast du schon einmal einen anderen
Controller ausprobiert?

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Das Register R20, in dem der Wert 255 bzw. 254 gehalten wird,
wird nur zur Ausgabe an PORTA und nirgends sonst verwendet. Dass die
Zeitschleifen unterschiedlich lang laufen, kann also nicht mit einem
Compiler- oder Programmierfehler zusammenhängen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@yalu,

Der erzeugte Assemblercode, bzw. das Hexfile ist einwandfrei. Laufen 
auch Beide im Simulator durch.

Der einzige Unterschied besteht aus:
SER       R20
statt
LDI    R20,0xFE

Und das ist so korrekt, damit wird das R20 Register zur Ausgabe auf 
PortA gesetzt. Das Timing ist exakt gleich.

@Egon,

Verhalten muss durch die Hardware begründet sein, mglw. defekter 
Controller. Was hängt alles an PortA.0 ? Eine Verbindung die dieses 
Verhalten, vielleicht einen Reset auslösen kann ? Kannst Du einen 
Schaltplan posten ?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:

> Der einzige Unterschied besteht aus:
>
> SER       R20
> 
> statt
>
> LDI    R20,0xFE
> 

Das ist beides ein LDI. SER ist nur Syntactic Sugar.

Mögliche Fehlerquellen:

-- Watchdog
-- Defekter µC
-- Unsaubere Spannungsverorgung
   (schwingt/sackt ein/Transienten bei Belastung)
-- Es kommt zu RESETs (zB durch Transienten bei Belastung)

Gibt es Abblockkondensatoren?
Wie wird VCC gemacht?
Wie ist RESET beschaltet? (100nF nach GND und 10k&Omega; nach VCC?)

Johann

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir mal das Layout angesehen. Der Abblockkondensator an AVCC 
ist recht ungünstig platziert. Löte doch mal einen 100nF an der 
Unterseite direkt an die Pins 30 und 31 des µC.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute einen Kurzschluß auf PORTA.

Laut erstem Post geht die LED hier nur ganz kurz aus
  PORTA =0xFF;     // Ab hier wird was heiß ;)      
  _delay_ms(1000); // Piff: Reset nach < 1sek
  PORTA =0x00;     // Wird nicht mehr ausgeführt
  _delay_ms(1000); // Wird nicht mehr ausgeführt 

Die LED wird nur vom Reset bis zum PORTA=0xFF aus sein.

Das soll funktionieren. Vieleicht sieht es aber nur so aus?
  _delay_ms(1000); // LED ist aus für 1s
  PORTA =0xFF;     // Ab hier wird was heiß ;)      
  _delay_ms(1000); // Piff: Reset nach < 1sek
  PORTA =0x00;     // Wird nicht mehr ausgeführt

Das soll funktionieren. Vieleicht sieht es aber nur so aus?
  PORTA =0x00;     // LED ist aus für 1s
  _delay_ms(1000); // LED ist aus für 1s
  PORTA =0xFF;     // Ab hier wird was heiß ;)      
  _delay_ms(1000); // Piff: Reset nach < 1sek

Zumindest passt das so zum Fehlerbild ;)

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu meinem Post oben:
Mit dem Abblockkondensator am "normalen" VCC sieht es kaum besser aus. 
Also auf der Rückseite auch noch gleich einen 100nF zwischen Pin 10 und 
11 setzen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist beides ein LDI. SER ist nur Syntactic Sugar.

Das ist aber schön. Da SER die Ausgabe des AVR Studios war, hatte ich 
allerdings keinen Grund dies umzudeuten.

Ändert nix daran daß der Code einwandfrei arbeitet und somit PortA.0 
direkt oder indirekt Auslöser für dieses Problem ist.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PortA.0 geht an SD0 der Netzwerkkarte, steck mal die Karte aus und 
probier's nochmal.

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
>> Das ist beides ein LDI. SER ist nur Syntactic Sugar.
>
> Das ist aber schön. Da SER die Ausgabe des AVR Studios war, hatte ich
> allerdings keinen Grund dies umzudeuten.
>
> Ändert nix daran daß der Code einwandfrei arbeitet und somit PortA.0
> direkt oder indirekt Auslöser für dieses Problem ist.

A0 war früher unbeschaltet, als es falsch lief, jetzt ist es SCL für 
einen PCF8574A mitsamt einem 10-k nach Plus (läuft immer noch falsch).

Wenn ich wieder dazu komme, werde ich mir den mal einen anderen 
Prozessor einsetzen und sehen, ob ich, wie Stefan schreibt, da und dort 
noch Kondensatoren unterbringen kann.

Hat mal jemand das "Programm" auf einem anderen Prozessor laufen lassen 
- gibt es da auch Probleme?

mfg
Egon

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>A0 war früher unbeschaltet, als es falsch lief, jetzt ist es SCL für
>einen PCF8574A mitsamt einem 10-k nach Plus (läuft immer noch falsch).

Na prima. Etwas funktioniert nicht, und dann wird nochwas angeschlossen.

>Wenn ich wieder dazu komme, werde ich mal einen anderen Prozessor
>einsetzen

Tu das.

>Hat mal jemand das "Programm" auf einem anderen Prozessor laufen lassen
>- gibt es da auch Probleme?

Wozu? Das Programm kann nur richtig laufen. Das der AVR-GCC
bei so einem simplen Programm Fehler macht dürfte unglaublich
unwahrscheinlich sein.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Egon,

Ich hatte beide Hex Files in den Simulator des AVR Studios geladen und 
dort simuliert. Beide Versionen laufen absolut einwandfrei.

Zumal unterscheidet sich die funktionierende Version von der nicht 
funktionierenden nur darin, daß der PortA.0 nicht gesetzt wird, sonst 
sind sie absolut identisch.

Das ist eindeutig ein Problem der HW.

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
>>A0 war früher unbeschaltet, als es falsch lief, jetzt ist es SCL für
>>einen PCF8574A mitsamt einem 10-k nach Plus (läuft immer noch falsch).
>
> Na prima. Etwas funktioniert nicht, und dann wird noch was angeschlossen.
>
Ist unproblematisch, weil das Webmodul nur wegen der bequemen Anschlüsse 
vorübergehend benutzt wird.


Ich glaube, der arme Port A.0 wird zu unrecht verdächtigt. Das mißliche 
Verhalten kann auch unterdrückt werden, wenn man schreibt
PORTA = 253;   oder = 251;, also den A.0 beibehält und andere Ports 
ausschaltet. Sogar PORTA = 1 ist gut. Also nichts gegen den A.0!

Also doch Spuk?

mfg

Egon

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> PortA.0 geht an SD0 der Netzwerkkarte, steck mal die Karte aus und
> probier's nochmal.

Also, ich habe mir Uli Radigs Schaltplan von oben bis unten 
durchgesehen, da gibt es keine Verbindung von PORTA.0 zu dem ENC28... , 
einzig und allein zu einem Stecker, wo analoge oder digitale Sachen 
angeschlossen werden können (der für meine derzeitigen Exercitien so 
bequem ist).

mfg
Egon

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prinzipiell werden Atmels Megas so gefertigt, daß man alle Portpins 
gleichzeitig einschalten kann. :D

Wenn's bei Deinem anders ist, dann ist's wohl eine Sonderversion.

Aber ist halt müssig weiter eine SW Fehlfunktion zu unterstellen, wenn 
man anhand des Compilats beweisen kann, daß es die SW auf keinen Fall 
sein kann.

Der PortA.0 wurde nur aufgrund der von Dir gegebenen Information 
verdächtigt.
Entweder ist in Deiner Schaltung der Wurm drin, oder im ATMega. Da Du 
bereits Probleme hattest, kennst Du nun möglicherweise den Grund dafür.

Da Du keinen Schaltplan angehängt hast, habe ich mich aus dem Internet 
bedient und dort eine Version gefunden, bei der PortA.0 mit der 
Datenleitung der Netzwerkkarte verbunden war.

Falls Du einen anderen Schaltplan hast, dann häng ihn an und man kann 
einen Blick drauf werfen.

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir den Resetpin mit dem Oszi angesehen, der hat unentwegt 
high-level, es sind keinerlei Einbrüche zu erkennen - während bei 
PORTA=0xFF das incriminierte Verhalten zu beobachten ist.

mfg
Egon

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:

> Da Du keinen Schaltplan angehängt hast, habe ich mich aus dem Internet
> bedient und dort eine Version gefunden, bei der PortA.0 mit der
> Datenleitung der Netzwerkkarte verbunden war.
>

Hallo MWS
Der Schaltplan ist bei

http://ulrichradig.de/ unter ETH_M32_EX
zu finden. Eine Netzwerkkarte gibt es da gar nicht.

Vielleicht sollte ich mir einfach einen anderen Controller beschaffen, 
einsetzen und abwarten, was passiert.

mfg
Egon

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Atmel aus irgendwelchen Gründen abschmiert wirst Du nix am 
Resetpin messen können.

Wenn hier was blinken würde, dann ist der Wurm drin:
#include <avr/io.h>           
#include <util/delay.h>  

int main(void)
{
 DDRA = 0xFF;
  PORTA =0x00;
  _delay_ms(1000);
   while (1)
   {
  PORTA =0xFF;       
  _delay_ms(1000);
  };
}
Wenn da nix blinkt, dann mal vor der Schleife den Port setzen und in der 
Schleife löschen, schauen was passiert.

Ah, Du meist das AVR Webmodul, als Webserver bezeichnet Ulrich Radig 
etwas anderes. Ja, Du hast recht, am PortA hängt nix dran.

Alle Pins durchgemessen, kein Schluss untereinander oder gegen Minus 
oder Plus ?

Ich kann Dir nur sagen, daß der Assemblercode so einfach und auch 
erkennbar einwandfrei ist, daß ein normal funktionierender AVR ihn 
garantiert verarbeiten würde.

Probier' mal PortD anzusteuern, der ist auch an SV1 rausgeführt.

Wobei RXD/TXD PortD.0 & PortD.1 sind. Solange Du das UART nicht 
einschaltest, arbeitet der als normaler Port. Wenn ich nix im Schaltplan 
übersehen habe, dann sind die 2 Pins nur noch mit der Buchse JP2 
verbunden, aber mit nix sonst. Also würd' sich der Port zum Testen 
Deines kurzen Codes eignen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Tip, wenn PortD einwandfrei funktioniert, dann häng dort an die 
Pins 0-4 fünf LED's ran und schreib das Register MCUSR gleich zu Anfang 
Deines Programmes an den Port raus und lösch dann MCUSR.

Sollte der Atmel ungewollt in den Reset gehen, so siehst Du an den LED's 
den Grund für den Reset. Datenblatt ATM644P, Seite 57, MCU Status 
Register.

Autor: GG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe soeben Dein Programm in meiner Testumgebung getestet,

Atmega644p, 16 Mhz alles ok. Led blinkt wie vorgesehen.

Gruß GG

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Wenn der Atmel aus irgendwelchen Gründen abschmiert wirst Du nix am
> Resetpin messen können.
>
> Wenn hier was blinken würde, dann ist der Wurm drin:
>
> #include <avr/io.h>
> #include <util/delay.h>
> 
> int main(void)
> {
>  DDRA = 0xFF;
>   PORTA =0x00;
>   _delay_ms(1000);
>    while (1)
>    {
>   PORTA =0xFF;
>   _delay_ms(1000);
>   };
> }
> 
> Wenn da nix blinkt, dann mal vor der Schleife den Port setzen und in der
> Schleife löschen, schauen was passiert.
>

Es blinkt nichts!
Wenn ich den Port  v o r der Schleife setze kommt es darauf an:
PORTA = 255  der alte Zustand
PORTA = 253  einmal kurz hell, dann dunkel.

Bis morgen
Egon

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sehr eigenartig. Aber da die Led die Zeit des Delays hell ist, scheint 
erst das Rücksetzen des Ports einen Reset auszulösen.

Probier mal die Hex Datei im Anhang, ist mit Bascom erstellt. Hab' mir 
den Assemblercode daraus angesehen, es sind einige Unterschiede zum GCC 
Code vorhanden, hauptsächlich wird ein Watchdogreset am Start 
ausgeführt, sowie alle Flags des MCUSR gelöscht.

Ein weiterer Unterschied ist, daß Bascom RETIS's in die Interrupttabelle 
reinschreibt. Schützt eigentlich nur vor freigegebenen Int's bei nicht 
definierten ISR's. Aber vielleicht wird durch einen HW Defekt ein 
Interrupt ausgelöst, der dann beim GCC ins Nirvana führt.

Aber: Versuch macht kluch :D

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Könntest du bitte genau formulieren, welchen Zustand WDTON gerade hat?
> Ich weiß, klingt blöde, aber das ist bei den Fuses ja immer noch zehnmal
> umgedreht :-)

Zehnmal invertiert = Originalzustand :-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tausend Mal berührt, Tausend Mal ist nix passiert!

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:

>
> Aber: Versuch macht kluch :D

Es blinkt, etwa im Sekundentakt.

Viele Grüße
Egon

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es blinkt, etwa im Sekundentakt.

Das sollte es auch, das war Dein Blinkprogramm nur in Bascom.

Füg' mal ganz zu Anfang Deines Programmes das hier ein:
asm volatile ("wdr");
  MCUSR &= 0xF7;

Bin mir nicht sicher, ob die C-Syntax für die Assembleranweisung so 
richtig ist, gibt aber sicher Mitschreiber hier die mich dann 
verbessern.

Diese Sequenz baut Bascom ganz zu Anfang ein, sonstiger gravierender 
Unterschied zu GCC ist wie bereits gesagt nur das Besetzen der 
Interruptvektortabelle mit RETI's um wildgewordene 
Interruptanforderungen heimzuschicken.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch zwei weitere mögliche Fehlerursachen:

- Die Fuses für die Takterzeugung sind falsch gesetzt, so dass der
  Quarzoszillator zwar an-, aber nicht zuverlässig weiterläuft. Du
  kannst ja mal alle aktuellen Fuse-Einstellungen posten, vielleicht
  sind auch noch weitere Verdächtige dabei.

- Die Versorgungsspannung ist nicht angeschlossen oder instabil. Dann
  nimmt sich der Controller den Strom möglicherweise woanders her, z.B.
  aus den Signalleitungen eines angeschlossenen ISP-Programmieradapters.
  Er läuft dann zwar, aber mehr schlecht als recht. Am besten misst du
  die Spannung mit dem Oszi direkt an den VCC- und GND-Pins des
  Controllers.

Autor: Jan Sielemann (dl7ln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
int main(void)
{
   DDRA = 0xFF;
   while (1)
   {
  PORTA =0xFF;       
  _delay_ms(1000);
  PORTA =0x00;
  _delay_ms(1000);  
  }; /* warum das Semikolon? */
}

Warum hast du nach Abschluss deiner While-Schleife ein ";" gesetzt?
Gruss
Jan

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, was die Außenbeschaltung des Ports angeht: Entsteht da vielleicht 
bei ungünstiger Kombination ein Kurzschluss?

Autor: Egon Müller (kpc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
yalu schrieb:
> Noch zwei weitere mögliche Fehlerursachen:
>
> - Die Fuses für die Takterzeugung sind falsch gesetzt, so dass der
>   Quarzoszillator zwar an-, aber nicht zuverlässig weiterläuft. Du
>   kannst ja mal alle aktuellen Fuse-Einstellungen posten, vielleicht
>   sind auch noch weitere Verdächtige dabei.
>
s.o. Das roten Zeichen an SPIEN kann ich mir zwar nicht erklären, es ist 
aber seit Anschluß des ISP-Programmers vorhanden

> - Die Versorgungsspannung ist nicht angeschlossen oder instabil. Dann
>   nimmt sich der Controller den Strom möglicherweise woanders her, z.B.
>   aus den Signalleitungen eines angeschlossenen ISP-Programmieradapters.
>   Er läuft dann zwar, aber mehr schlecht als recht. Am besten misst du
>   die Spannung mit dem Oszi direkt an den VCC- und GND-Pins des
>   Controllers.
Den Effekt hatte ich mal nach einem Sicherungsfall. Aber hier ist nichts 
anderes dran und die Spannung am Vss-Pin ist stabil ohne Einbrüche - mit 
und ohne ISP-Programmer

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan Sielemann schrieb:
>
> Warum hast du nach Abschluss deiner While-Schleife ein ";" gesetzt?
> Gruss
> Jan

Stimmt, ist überflüssig
mfg
Egon

Autor: Egon Müller (kpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> Hm, was die Außenbeschaltung des Ports angeht: Entsteht da vielleicht
> bei ungünstiger Kombination ein Kurzschluss?

Ich benutze nur eine einzige LED mit Vorwiderstand, die ich je nach 
Bedarf manuell von Port umstecke.
Egon

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt mal das angeblich nicht funktionierende
HEX-File in einen ATMega644 gebruzelt. 8 LEDs blinken
schön vor sich hin.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die aktuellen Fuse-Einstellungen sind fast ok: Die Fuses für die
Takterzeugung stehen nach Datenblatt auf

  CKSEL3..1=111:         low power crystal osziollator, 8-16MHZ
  CKSEL0=1, SUT1..0=00:  ceramic resonator, slowly rising power,
                         start-up time 1K CK, additional delay 14CK+65ms
                         (AVR-Studio zeigt "Crystal" an, aber dem
                         Datenblatt würde ich eher trauen)

Die Start-up-Time von 1K CK ist für einen Resonator richtig, für einen
Quarz werden aber 16K CK, also CKSEL0=1 und SUT1..0=11 empfohlen. Das
erklärt zwar die Fehlfunktion nicht, da dadurch nur dem Oszillator
lediglich mehr Zeit zum Einschwingen gegeben wird, trotzdem würde ich es
ändern.

16MHz ist die maximale Frequenz, für die der Low-Power-Modus des
Oszillators verwendet werden kann. Vielleicht hast du einen komischen
Quarz erwischt, der lieber im Full-Swing-Modus schwingt. Dieser wird
CKSEL3..1=011 aktiviert und reicht bis 20MHz, so dass noch etwas mehr
Luft nach oben bleibt.

Die anderen Einstellungen sind ok.

Die Fuse-Einstellungen für Pessimisten wäre also

  extended: 0xFF
  high:     0xD9
  low:      0xF7  <- geändert, bisher 0xCF

Ich habe zwar keine allzu große Hoffnung, dass sich dadurch etwas
ändert, aber ein Versuch ist es wert.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.