ATMega128: System freeze sobald PORTD als Output definiert

[Ralph H. (rheller)]

Hallo Gemeinde

Ich nehme an,fuer Euch Cracks ist diese Frage eine Lappalie.Ich komme 
dabei jedoch nicht weiter.

In meinem ATMega128 System verwende ich Timer0 und Timer1. Diese 
funktionieren soweit auch einwandfrei und generieren Interrupts alle 
500ms und 10ms. Sobald ich nun PortD komplett als Output definiere, 
bleibt das System nach dem Hochladen des Programmes stehen. Wenn ich 
hingegen nur alles ausser PD1 als Output definiere (also DDRD=0xfd), 
dann laeuft alles weiterhin.

Dies bringt mich zur Vermutung, dass irgendwelche Timers aus welchen 
Gruenden auch immer diese Leitung mitverwenden. Im Datasheet habe ich 
hierzu aber nichts gefunden. Was koennte die Ursache sein?

Weitere Infos:
Fuse Registers: FF99FE (extended, hi, lo)
Timer0: CTC mode 2, prescale 256
Timer1: CTC mode 4, prescale 8
TIMSK Register: OCIE0 und OCIE1A gesetzt
SPI: SPE, MSTR, SPR0 gesetzt

Jegliche Tipps sind sehr willkommen.

Viele Gruesse und schon mal besten Dank, Ralph

[Magnus M. (magnetus)]

Ich befürchte dass der Code hilfreicher wäre.

[Magnus M. (magnetus)]

Nachtrag:

Auf PD1 liegen SDA (TWI-Interface) und INT1 (externer Interrupteingang).

Ich tippe mal darauf dass du INT1 versehentlich enabled und keinen 
Interrupthandler dafür implementiert hast.

[Ralph H. (rheller)]

Hallo Magnus

Besten Dank fuer Deine Antwort. TWI habe ich gezielt versucht 
auszuschalten. Ich versuche in einer zweiten Antwort ein File mit einem 
Auszug meines Programmes anzuhaengen. Das Ganze ist ansonsten etwas 
unuebersichtlich und gross.

Gestern war ich auf einer ausgedehnteren Motorradtour in den Alpen und 
somit komme ich erst heute wieder zum Forum behandeln.

Viele Gruesse,

Ralph

[Ralph H. (rheller)]

Salut zusammen

Anbei folgt noch der versprochene Auszug. Der Zweck der ganzen Chose 
ist, eine Nixie-Uhr mit 6 Digits und Funkuhrmodul (Conrad) sowie 
Temperatursensoren zu bauen (als Geschenk fuer einen Arbeitskollegen, 
welcher Ende des Monats pensioniert wird).

Viele Gruesse,

Ralph

[Magnus M. (magnetus)]

Füge mal probehalber die folgenden zwei Interrupthandler ein:

ISR(INT1_vect)
{
   return;
}

ISR(TWI_vect)
{
   return;
}

Wenn der Controller dann nimmer "abstürzt" hast du offensichtlich 
irgendwo einen der INTs enabled.

[P. S. (Gast)]

Ralph Heller schrieb:

> Ich versuche in einer zweiten Antwort ein File mit einem Auszug meines 
Programmes
> anzuhaengen.

Keinen Auszug posten, sondern ein minimiertes, komplettes Programm, das 
den Fehler reproduziert.

[Ralph H. (rheller)]

Hallo zusammen

Das mit der leeren Definition der beiden Interrupt Vektoren hat leider 
nichts gebracht. Hingegen verhaelt sich heute mein ganzes System so, 
dass oft (haeufiger als jedes 2. mal) der Download mittels meines 
Dragons stehen bleibt (timeout), und dabei eigentlich immer irgendwelche 
Errors ins Outputwindow reinschreibt.

Nach Nachschauen habe ich gesehen, dass es mittlerweile eine neue 
Studioversion gibt(habe bis jetzt v5 Beta 2 verwendet; lief soweit 
eigentlich ganz gut). Nun bin ich am Runterziehen der neuesten Version 
und komme heute somit zu keinen Versuchen mehr. Werde dann morgen mal 
schauen, ob sich das Ding nun anders verhaelt (kann ja auch ein Problem 
des Debuggers oder der Studioversion sein, man weiss ja nie in dieser 
Branche...).

Schoenen Abend noch,

Ralph

[holger (Gast)]

>(kann ja auch ein Problem des Debuggers

Läuft das Programm OHNE Debugger?

[Ralph H. (rheller)]

Hallo Gemeinde

Inzwischen bin ich wieder im Business, mein System laeuft soweit wieder 
ganz gut. Nach ein paar Versuchen mit alten Programmen (ganz einfachen) 
habe ich festgestellt, dass ich alle diese zum Stoppen bringe (sprich 
auch die Timer-Interruptroutinen laufen nicht mehr), sobald ich bei der 
Initialisierung DDRD=0xff; einfuege. Bei 0xfd funktionieren sie jeweils.

Nach Nachmessen der einzelnen Leitungen habe ich festgestellt, dass 
wahrscheinlich ein 'Kurzschluss' zwischen Pin26 und Pin23 vorhanden ist. 
Letzteres ist ja ein Eingang des Quartzes (Resonators in meinem Fall), 
und dann kann ja nichts mehr gehen.

Ich muss aber dies morgen noch im Geschaeft verifzieren; dort ist die 
passende Loet- und sonstige Ausruestung vorhanden (es geht dabei ja auch 
um die 'Optik' oder, anders gesagt, ich sehe ohne Hilfsmittel nicht mehr 
ganz alles; ja ja,die Jahre....).

WerdeEuch auf jeden Fall morgen berichten, ob dies des Drudels Kern war.

Viele Gruesse, Ralph

[Magnus M. (magnetus)]

Ralph Heller schrieb:
> Hallo Gemeinde

Hallo Herr Pfarrer ;o)

> Nach Nachmessen der einzelnen Leitungen habe ich festgestellt, dass
> wahrscheinlich ein 'Kurzschluss' zwischen Pin26 und Pin23 vorhanden ist.

Auf diesen Fehler wären wir hier per Ferndiagnose vermutlich nie 
gekommen.

> Letzteres ist ja ein Eingang des Quartzes (Resonators in meinem Fall),
> und dann kann ja nichts mehr gehen.

Absolut einleuchtend.

> Ich muss aber dies morgen noch im Geschaeft verifzieren; dort ist die
> passende Loet- und sonstige Ausruestung vorhanden (es geht dabei ja auch
> um die 'Optik' oder, anders gesagt, ich sehe ohne Hilfsmittel nicht mehr
> ganz alles; ja ja,die Jahre....).

Kurzschluss ist Kurzschluss. Daheim genauso wie im Büro. Die Frage ist 
nur "wo?".

[Ralph H. (rheller)]

Ja ja,auch Ferndiagnosen haben eindeutig ihre Grenzen...

Es war wirklich eine schon beinahe unsichtbare Loetbruecke. Nach 
Entfernen dieser  kann nun PD1 problemlos verwendet werden.

Aber Eure Ferndiagnose hat mir zumindest dahingehend geholfen, dass ich 
nichts machen moechte, was aus systembedingten Gruenden gar nicht gehen 
kann. Somit also besten Dank an alle.

Nun kann ich also mit der 'Arbeit' beginnen und die Software entwickeln; 
das Wochenende passt dazu ja.

Viele Gruesse,

Ralph