Rücksprung Probleme

[oberallgeier]

... Beim Debuggen ... zurückspringen nicht in die Main, sonderen irgendwo ...

Ich bin ja nicht sicher, dass es ein Parameterproblem ist - Du deklarierst nämlich Deine Prototypfunktionen ohne Parameterdefinition.

...
void LED_ON();    //Prototyp
...

Auch die Funktion selbst ist ohne Parameterdefiniton . . . bei mir sieht ein Funktionsprototyp etwa so aus:

...
  void itxt_rn (void);          // "\r\n"
...

sprich: es ist eindeutig definiert, dass die Funktion ohne Parameter aufgerufen wird und auch keine/n zurückgibt. Lediglich der Funktionsaufruf geht (meines Wissens) mit der einfachen, leere Klammer für die Parameterübergabe. Meckert der Compiler das nicht an???

[Furay]

Hallo oberallgeier,

der Compiler hat dies nicht angemosert, nicht mal eine Warnung ist da.
Ich hab nun beim Prototyp und bei der Funktion nun das void reingeschrieben, leider auch dies ohne Erfolg.

Grüße und Danke

Furay

[oberallgeier]

Doofe Frage: Wo hängt denn die LED? Du schaltest ja (je nachdem ob die LEDs gegen GND oder VCC liegen) die Ports PC2, PC3 und PC4 ein, die anderen aus (oder eben nur die aus und die andern - dauernd - ein).

[Furay]

Es Hängen nur 3 LEDs an PC2,3 und 4. diese werden über eine Transistorstufe geschalten.

Wenn ich den Port direkt in der Schleife (so wie in den Funktionen) beschreibe, funktioniert das blinken auch problemlos.
Der Funktionsaufruf macht nur Probleme...

[Klebwax]

Die leere Klammer ist schon ok, obwohl man dort ein void einsetzen sollte. Der ganze Code sieht gut aus.

Ich könnte mir vorstellen, daß der Stack nicht in Ordnung ist. Da das aber der Start-Up Code automatisch erledigt, könnte das nur passieren, wenn der Compiler für die falsche CPU übersetzt. Der Stackpointer könnte dann auf eine Adresse zeigen, an der kein RAM existiert. Ist aber nur eine dürre Vermutung

MfG Klebwax

[Furay]

Ich hab nochmal mit "Device Programming" mal den Flash gelöscht und neu beschreiben. Ebenso geprüft was für ein Chip erkannt wird.

Der ausgewählte Chip passt und nach dem löschen und beschreiben hab ich das Problem nach wie vor.

[oberallgeier]

Sorry, musste mir erst das Datenblatt laden. Das neueste Datenblatt /Rev. 8151H–AVR–02/11/ schreibt:

"... The Atmel®AVR® ATmega128A is by default shipped in ATmega103 compatibility mode ..." und
"...Port C also serves the functions of special features of the ATmega128A as listed ..." und
"... PORTC will be output during first power up, and until the ATmega103 compatibility mode ..."

Vielleicht mal den ATmega103 compatibility mode abschalten (ich will einfach nicht für Dich das ganze DAtenblatt durchackern).

[Furay]

Dankeschön. Das war das Problem.
Ich hab bei den FUSES das M103 umgestellt und schon gings...

Für die Nachwelt vielleicht... hier steht es auch nochmal:

http://www.mikrocontroller.net/articles/AVR_Checkliste

Grüße

Furay

[oberallgeier]

... Das war das Problem ... Für die Nachwelt vielleicht ...

Die Nachwelt wills nicht lernen; ich habe das schon soo oft und viel kürzer geschrieben:
Der Umgang mit Mikrocontrollern ohne das zugehörige Datenblatt zu lesen ist eines der letzten großen Abenteuer unserer Tage.

[SprinterSB]

> der Compiler hat dies nicht angemosert,
> nicht mal eine Warnung ist da.

Dann setze -Werror=strict-prototypes -Werror=missing-prototypes