ATmega8 initialisiert bei Power on nicht immer

[Crazy:Hardware]

Guten Abend,

ich habe eine kleine Schaltung mit einem ATmega8 gebastelt.
Als Takt benutze ich den internen RC-Oszillator ( 8MHz ), leider muß ich nach fast jedem Power on erst einen manuellen Reset durchführen, damit die Ports korrekt initialisiert werden und die Schaltung wie gewollt funktioniert.

Hat jemand eine Idee was das sein könnte?

Ich habe verschiedene ATmega8 ausprobiert, bei allen das gleiche Problem.

Es ist auch nicht so, das der µC garnicht arbeitet, eine in der Programmschleife eingearbeitet Led blinkt und signalisiert Aktivität.

MfG Hansi

[x-ryder]

schick mal bitte deine schaltung!!!

Die Schaltung ist nicht kompliziert, ich beschreide Sie am besten mal kurz:

Der ATmega arbeitet als I2C-slave, angeschlossen an einem rn-control-Board.

Über den I2C-Stecker vom rn-controlboard wird die Schaltung mit 5V versorgt. Den Resetpin habe ich über 10KOhm an VCC geklemmt.
Außer SDA/SDL sind die Ports Portc.3 / Portc.4 beschaltet, an dem einen ist ein Funkempfänger und an dem anderen ein Sender.

Das Modul benutzt die Funksignale des FS20-Funksystems von ELE / Conrad-Elektronik. Funke und Empfang klappen einwandfrei, auch der Datentransport über TWI arbeit super, bis auf den einen Manko mit dem "Anlauf". Ich habe in einer Do/Loop schleife eine Led ( Portd.4 ) eingebaut, manchmal blinkt die Led wie sie soll, aber Empfänger geht nicht oder Sender geht nicht, oder TWI funzt nicht , manchmal bleibt die Led auch aus. Die einzige Erklärung ist für mich, das die Ports nicht korrekt initialisiert werden. Wie geschrieben, nach Reset ( ohne Spg.-Abschaltung ) funzt es.

Gruß Hansi

[Andree-HB]

...ähmm, soweit ich weiss taktet der interne Oszillator doch nicht mit 8Mhz sondern nur mit 1 Mhz. Vielleicht da mal gucken...

[x-ryder]

und du hast nicht zufällig nen schaltplan?

[Pascal]

...ähmm, soweit ich weiss taktet der interne Oszillator doch nicht mit 8Mhz sondern nur mit 1 Mhz. Vielleicht da mal gucken...

der Takt des internen Oszillators beim ATMEGA8 ist variabel, man kann 1, 2, 4 oder 8MHz einstellen

@x-ryder,

die Beschreibung entspricht doch dem Schaltplan. Es funktioniert ja auch,
nur der Power-on Reset arbeit wohl nicht wie gewollt.
Ich habe bisher nur ATmega8L ( 2,7V bis 5,5V ) einer Serie verwendet.
Heute wurden andere ATmega8 ( andere Serie ) geliefert die ich testen werden. Zusätzlich werde ich den Resetpin über einen 100nF Kondensator
auf low ziehen. Mal schauen ob das hilft.
Ich werde mich heute Nachmittag diesbezüglich wieder melden.

Gruß Hansi

So, ich habe nun den Resetpin zusätzlich mit dem Kondensator beschaltet
und einen ATmega8 16PI ( Industrie mit erweitertem Temp.-Bereich )
eingesetzt.
Der Erfolg: Fehler tritt anscheinend etwas seltener auf, aber er tritt auf.

Bye Hansi

PS.:
Kann ja leider nicht reingucken, ob der TWI nur nicht arbeitet oder die Ports nicht etsprechend Eingang/Ausgang initialisiert sind.
Programmiert habe ich die Sache mit dem Bascom-AVR mit Inline Assembler

Ach so, vieleicht noch als Zusatz-Info.

Wenn Daten empfangen werden, dann hört bedingt durch die Auswertzeit die Led kurz auf zu blinken. Das ist manchmal nicht der Fall, weshalb ich darauf schließe, das der Port garnicht gelesen wird.
Das gleiche gilt auch für das senden.
Bei einem manuellen Reset wird nur der ATmega8 resetet, nicht die Sende- / Empfangsmodule weshalb ich einen Fehler dieser Module ausschließe.

Gruß Hansi

Ich bin jetzt zu einer neuen Erkenntnis gekommen.

Wenn das Empfangsmodul nicht eingesteckt ist funzt es richtig, zumindest der für das Senden zuständige Teil.

Das Empfangsmodul liefert auch schon während des Resets Impulse an
Pinc.3 , kann der Fehler damit zusammen hängen?
Wird durch die Impulse der Programmiermodus oder ähnliches eingeleitet?

MfG Hansi

[Crazy_Hardware]

Ups, die letzten Postings waren natürlich von mir ;:)

[Crazy_Hardware]

Allgemeine Ratlosigkeit?

Gruß Hansi

[nikolaus10]

Na, ja koennte natuerlich auch eingestreute HF sein.
Nur so eine Idee von mir.

MFG

[Bender]

Könnte das vielleicht ein Problem mit der Versorgungsspannung sein? Evtl. mal nen Puffer-Kondensator einbauen...

[Crazy_Hardware]

Also, Versorgungsspannung konstannt 5V. Natürlich alles über Elkos gestützt.

Was mir allerdings aufgefallen ist, der Ausgang Pinc.2, an dem das Sendemodul hängt kommt im High-Zustand nur auf 0,8V ( Schaltungsbeding Basis-Emitterspg. einer Transistortreiberstufe)
Aber wie geschrieben, der Pinc.2 macht mir ja auch keine Schwierigkeiten.

Pind.0, welchern ich auf die Intleitung des I2C-Busses gelegt habe schaltet im Fehlerfall ohne ersichtlichen Grund auf Low.
Ich habe alle Befehle die den Port auf Low schalten auskommentiert und trotzdem.
Mir kommt so der Verdacht, das die bei der Initialisierung auf High-geschaltete Leitung Pinc.2 die µC intern zu stark belastet und diesen Fehler bei der Initialisierung hervorruft.
Probiere ich sofort aus und werde gleich berichten.

Gruß Hansi

[Crazy_Hardware]

Ne, war auch nicht der Gund.

Ich habe den Ausgang Pinc.2 bis zum Ende der Initialisierungsroutine auf low gesetzt, also praktisch unbelastet.
Der Fehler tritt immer noch auf. Portb.0 wird ohne einen erkennbaren Grund auf Low gesetzt bzw. nicht als Ausgang initialisiert.
Es muß damit zusammenhängen, das während des Resets Impulse an Pinc.2 ( ca. 1ms Periodendauer ) anliegen.

Auch die besagten HF-Störungen schließe ich aus, der Sender ist zu dem Zeitpunkt nicht aktiv, woher sollten die Störungen kommen?
Auch die Tatsache, das wenn es nach dem Reset läuft alles 1a im Dauertest funktioniert spricht dagegen.
Bei den ISP-Pins leiten Impule während des Resets den Programmiermodus ein, was könnte aber am Pinc.2 liegen?
Es ist weder RS232, noch TWI, noch ein von SPI genutzter Pin.

Einfach mal andere Ports benutzen? Hm, sehe ich schon als letzte Möglichkeit.

Es tritt aber bei allen ATmega8-Versionen auf.

Bye Hansi ....grübel, grübel, grübel.

PS.: Werde mir erst mal die Spannungsanpassung noch einmal genau vornehmen. ( 3V Funkmodule am 5V ATmega )

Nächster Rückschlag,

ich habe als Eingang den Pinc.3 gegen Pinc.1 getauscht.
Gleiches Spiel !

Als nächstes werde ich die Initialisierung der Ports softwaremäßig
solange durchführen bis alles wie gewollt gesetzt ist bevor ich die
eigendliche Programmschleife anspringe.

Programmieren tue ich im übrigen mit Bascom AVR. Ist da vieleicht ein
Compiler-Fehler bekannt?

Bye Hansi ...ist schon sehr merkwürdig

[Crazy_Hardware]

Guten Morgen,

nächster Test gescheitert.

Nachdem ich festgestellt habe, das im Fehlerfall Portb.0 konstant auf Low gezogen bleibt und sich auch programmtechnisch nicht wieder auf High
ziehen läßt habe ich den Port mit dem Nachbarport Portd.7 getauscht.
Ich habe sogar dieses mal nicht nur die Pullup-Widerstände der freien Ports aktiviert, sondern gleich eine Brücke auf VCC gelegt, um ein Flattern
dieser Ports auch vor der Initialisierung ausschließen zu können.

Was soll ich schreiben, erneut Fehlanzeige.
Ich habe jetzt sogar das Empfangsmodul selber getauscht, auch kein Erfolg.
Das einzige was ich bisher weiß ist, Ohne Empfangsmodul funktioniert der für das Senden zuständige Teil nach jedem! Power-on.
Wer jetzt denkt "klar, ist doch wohl unabhängig voneinander" liegt falsch.
Sende- und Empfangsroutine nutzen den TWI-Interupt und beide Routinen
nutzen den gleichen Timer für die Impulslänge.

Ich habe sogar in der eigendlichen Programmschleife eine Initroutine für die Ports eingebaut, Die µC läßt sich davon garnicht beeindrucken.

Als nächstes werde ich den Ausgang des Empfangsmoduls über ein Und-Gatter bis nach der Initialisierung blocken, mal schauen was dat Dingen dann macht.

Gruß Hansi

[Crazy_Hardware]

Ach so,
Das eingesteckte Empfangsmodul macht auch dann keine Probleme, wenn
der Datenausgang nicht angeschlossen ist.

[edgar]

bei mir verhält sich das ähnlich. allerdings glaube ich wenn der isp programmieradapter nicht eingesteckt ist gibts keine probleme.
gruß werner...

Hallo Werner,

der ISP-Adapter steckt auf dem Master-Board, welches über den TWI mein Funkmodul nur steuert und mit Strom versorgt.
Das kann es auch nicht sein.
Ich habe bei weiteren Tests festgestellt, das der Takt des Prozessors ohne Empfangsmodul viel schneller hochläuft ( Blinkfrequenz der Loop-Led ).
Es ist auch schon passiert, das nach dem "Hochfahren" ohne Empfangsmodul und anschließendem hineinstecken des selbigen der Atmega einfach abgestürzt ist.

Noch einmal zur Verdeutlichung ( habe leider keinen Schaltplan )

Die 5V-Versorgung aus dem I2C-Bus gehen auf einen 3V Festspannungsregler für die Funkmodule.
Den 3V ausgang des Empfangmoduls habe ich über einen 4K7 Ohm Widerstand auf die Basis eines NPN Transistors geführt, der mit dem Emitter auf GND und dem Kollektor über einen 10K Ohm Widerstand auf 5V gelegt ist. Der Kollektor führt direkt auf Pinc.3 des ATmega8.
Je nach Schaltzustand des Empfangmoduls liegen demnach endweder niederohmig GND am eingang oder 5V über den 10K Widerstand.
Das der Atmega teilw. sogar abstürzt oder wesendlich langsamer hochfährt kann ich mir nur noch über einen Kurzschluß am Eingang erklären was wiederum bedeutet, der ATmega muß den Port niederohmig auf 5V geschaltet haben wenn das Empfangsmodul den KolleKtor des Transistors niederohmig auf GND schaltet.
Das geht aber nur wenn der Eingang nicht als Eingang sondern als Ausgang geschaltet ist.
Ich habe aber nicht nur "config Pinc.3=Input" sondern auch innerhalb des Programms an verschiedenen Stellen in Assembler den Config-Befehl nach gebildet.

Gruß Hansi

[Crazy_Hardware]

Guten Morgen,

ich habe jetzt Fas Fusebit für die Startverzögerung von 64ms auf 4ms
geändert. Das Startverhalten hat sich deutlich verbessert.

Weitere Beobachtungen haben ergeben, das tatsächlich nicht immer alle Ports korrekt initialisiert werden. Es ist mittlerweile auch schon vorgekommen, das die Stromaufnahme der Schaltung von ca. 50mA auf bis zu 290mA angestiegen ist.
Ich vermute, das die als Eingang geschaltetetn Ports, welche ich fest direkt auf GND oder VCC ( ohne Widerstand ) gelegt habe in dem Moment
auf Ausgang standen.

Gruß Hansi

[x-ryder]

und es kann nicht sein das der controller kaputt ist?

Nein, ich habe 3 verschiedene Controller 2 verschiedener Serien
ausprobiert, daran liegt es nicht.

Heute habe ich alles entfernt, was beim Power-on einen Kurzschluß der Ports oder ähnlich verursachen kann, d.h. außer die Versorgungsspannung und das Empfangsmodul ( Spannungsanpassung 3V -> 5V ) über einen 470 Ohm Widerstand am Pinc.3 keine weitere Beschaltung.

Fehlanzeige !

Softwarefehler habe ich dadurch ausgeschlossen, indem ich alle Interupts gesperrt habe und keinen Interuptvector umgebogen habe.

Also nur noch Initialisierung des Pinc.3 als Eingang und Pind.4 als Ausgang für eine Led, ob ein Signal Empfangen wurde und dann eine Endlosschleife.

Es passiert trotzdem.

Aber wie gesagt, wenn es nach dem Einschalten funktioniert, dann läuft es auch tagelang so weiter.

Vieleicht noch als kleine Info dabei:
Die von mir benutzte Beschaltung des Eingangports funzt an meiner C-Control 2 ohne zu murren.
Der ATmega8 soll die CC2 eigendlich nur von der De-/Enkodierarbeit endlasten und die Daten über I2C an den Master schicken.

Gruß Hansi

[Crazy_Hardware]

Guten Morgen,

für heute habe ich mir was ganz tolles ausgedacht!

Ich werde den ATmega8 probehalber gegen einen ATmega32 austauschen.

Meine ersten Programmzeilen hatte ich auf dem rn-control Board geschrieben und da gab es keine Probleme hinsichtlich des Empfangs.

Gruß Hansi ...ich werde heute oder morgen auf jedenfall darüber berichten

[Crazy_Hardware]

Guten Morgen,

das mit dem Adapter hat gestern nicht merh geklappt, allerdings habe
ich eine Grundschaltung mit dem ATmega8(L) (3V ) aufgebaut wo ich
das Empfangsmodul direkt anschließen konnte.

Was soll ich schreiben, das Verhalten ist absolut das gleiche.

Das Unterprogramm für den Empfang ist ziemlich einfach und benötigt
außer ein paar Variablen und den Timer keine Besonderheiten, nicht
mal einen Interupt.

Bye Hansi

[Crazy_Hardware]

Uhhhhaaaaa,

ich fasse es nicht! Es klappt !!!

Was für ein blöder Bascom-AVR !

Ich habe in der Empfangsroutine die lokalen Variablen gegen globale
Variablen ersetzt und es funktioniert plötzlich.

Die Stackgröße hatte ich meines wissens nicht überschritten und es hat ja auch funktioniert nur ebend nicht bei jedem Power-on.

Gruß Hansi ...es gibt Dinge, die kann man nicht verstehen

Ps.: Noch mal schönen Dank an alle, die mir mit Rat und Tat beigestanden haben

Hi Crazy_Hardware,

hat sich dein Prob gelöst?
Was für Funkmodule benutzt du?

[Crazy_Hardware]

Hallo Gast,

ja, es waren die Variablen, habe das aber nicht weiter untersucht.

Ich benutze das HFE868 als Empfänger und das HFS868 als Sender, beide Module arbeiten auf 868,35 MHz und sind bei ELV erhältlich.
Das sind die Originalmodule aus dem FS20-Funksteuerungs-System von ELV.

Gruß Hansi ....warum hat denn Gast keinen Namen?

[kwalter]

Hallo Hansi,

versuche mich auch gerade an der Steuerung der FHZ 1000, habe aber noch massive Probleme mit dem Protokoll, möchte eigentlich nur, das was die FHZ 1000 sendet und empfängt mit einem PC zu Testzwecken protokollieren.

Gibt es zu Deinem Projekt eine Dokumentation oder sogar Beispielcode?

Wenn ja, würde ich es nett finden, wenn Du mir eine kurze Nachricht zukommen lässt.

MfG
kwalter

[Crazy_Hardware]

Hallo Kwalter,

was steuerst Du denn mit der FHT1000 ?

Das Hauptproblem ist das Protokoll, also welche Bedeutung die einzelnen Bytes haben. Für die FS20-Geräte sind die weitgehend bekannt, das Protokoll der FHT80 ( Heizungssteuerung ) ist auch mir nicht bekannt.

Gruß Hansi

[kwalter]

Hallo Hansi,

FHT80b und FHT80V (Raumregler und Ventilsteuerung)

Gruß Kwalter