C: Rücksprung aus Unterfunktion klappt nicht

[Robodriver (Gast)]

Hallo,

ich bin hier seit einigen Tagen total am Verzweifeln. Ich starte gerade 
ein neues µC-Projekt (Habe schon sehr viele Projekte gemacht) und 
scheitere an den ersten drei Zeilen und weiß absolut nicht mehr weiter 
woran es liegen könnte.

Mein Projekt besteht aus folgenden drei Dateien:

main.c:

#include <avr/io.h>

#include "stuff.h"

int main(void)
{

  DDRA |= 0x08;

  while(1)
  {
    waitms(4);
    PORTA ^= 0x08;
  }

  return 0;

}

stuff.c:

#include <util/delay.h>

#include "stuff.h"


void waitms(uint16_t milliseconds)
{
  uint16_t i;

  for(i=0;i<milliseconds;i++)
  {
    _delay_ms(1);
  }
}

stuff.h:

#ifndef STUFF_H
#define STUFF_H

void waitms(uint16_t milliseconds);

#endif

Hier sollte ja der Pin PA3 alle 4ms Toggeln.
Statt dessen macht er gar nichts. Über mehrere Tests habe ich nun 
herausgefunden: Die Funktion waitms wird aufgerufen und auch bis zum 
Ende durchlaufen. Doch danach springt er nicht in die main-while zurück, 
sondern startet das Programm von Anfang an neu, aber ohne Reset
Das zeigt sich daran, das wenn ich den Pin-Toggel befehl direkt nach 
DDRA |= 0x08; schreibe, dann Toggelt der Pin tatsächlich alle 4ms...

Und es kommt noch besser: Wenn ich die Funktion waitms direkt in die 
main.c mit rein nehme funktioniert das Programm tadellos. Probleme 
Treten erst auf wenn die Funktion in der stuff.c liegt.

Ich finde das langsam sehr kurios. Habe das Projekt schon zwei mal neu 
aufgesetzt, ohne Erfolg. Mit der vorliegenden Entwicklungsumgebung und 
Compiler habe ich vor ein paar Wochen noch ein anderes Projekt 
fehlerfrei Kompiliert und genutzt.

Zu dem Workaround:
- ATMega128 (Brownout und Watchdog sind aus, Externer Quarz 8MHz)
- WinAVR20090313
- Editor: Codeblocks

Vielleicht kennt jemand das Problem und kann mir helfen?

[Cyblord -. (cyblord)]

Robodriver schrieb:
> Zu dem Workaround:
> - ATMega128 (Brownout und Watchdog sind aus, Externer Quarz 8MHz)
> - WinAVR20090313
> - Editor: Codeblocks
>

Welcher Workaround?

[Peter II (Gast)]

die häufigste ursache bei diesem Problem war bis jetzt immer das der 
falsche Prozessortype eingestellt war. Damit stimmt der Stack nicht und 
das Return geht schief.

Zur not mal ein Blick in den ASM-Code werfen, dort solle man sehen 
welcher werte der Stack hat.

[Peter D. (peda)]

M103-Fuse

Peter

[Karl H. (kbuchegg)]

Peter II schrieb:
> die häufigste ursache bei diesem Problem war bis jetzt immer das der
> falsche Prozessortype eingestellt war. Damit stimmt der Stack nicht und
> das Return geht schief.

In gewisser Weise hast du sogar recht :-)
Nur das diesmal nicht im AVR-Studio der 'falsche Prozessor' eingestellt 
ist, sondern am µC selber.

Mega128 - fabrikneu:
M-103 Fuse abschalten.

[Robodriver (Gast)]

Juhuuu Danke, ihr seid spitze :)

an der M103 Fuse lag es...
Wenn das solche Auswirkungen hat, versteh ich allerdings nicht warum 
Atmel die defaultmäßig setzt...

[Karl H. (kbuchegg)]

Robodriver schrieb:
> Juhuuu Danke, ihr seid spitze :)
>
> an der M103 Fuse lag es...
> Wenn das solche Auswirkungen hat, versteh ich allerdings nicht warum
> Atmel die defaultmäßig setzt...

Das versteht wohl keiner, warum Atmel einen µC verkauft, bei dem man 
erst mal eine Fuse löschen muss, damit man innen kriegt, was aussen 
drauf steht.

Da hat es wohl in der Vergangenheit einen Kunden mit sehr viel Geld 
gegeben, der eigentlich M103 haben wollte ....

Entweder das, oder da war seehr viel Alkohol im Spiel :-)

(Zumindest ist das Symptom sehr spezifisch. M128 - return geht schief -> 
M103 Fuse)

[Peter II (Gast)]

Karl Heinz Buchegger schrieb:
> In gewisser Weise hast du sogar recht :-)
> Nur das diesmal nicht im AVR-Studio der 'falsche Prozessor' eingestellt
> ist, sondern am µC selber.
>
> Mega128 - fabrikneu:
> M-103 Fuse abschalten.

man könnte auch das Projekt an den Prozessor anpassen