Merkwürdiges Verhalten eines Atmega16 mit C++

[Sebastian (Gast)]

Guten Abend,

ich habe ein merkwürdiges Verhalten eines Atmega16 und bräuchte mal nen 
Rat.

Ich habe ein recht umfangreiches C++-Programm auf einem Mega16 laufen, 
welches auch an sich funktioniert.
Wenn ich nun einer Funktion, welche einen uint32t als Parameter 
verlangt, beispielsweise einen uint16t übergebe, ohne ihn zu casten, 
meckert erstens AtmelStudio 7 nicht und zweitens, ich bekomme sehr 
merkwürdige, fast zufällige Ausfallerscheinungen: Zunächst bleibt der µC 
einfach irgendwann stehen, nach einigen Neustarts werden dann z.B. 
(andere) Variablen in ganz anderen Codebereichen nicht mehr ordentlich 
beschrieben. Manche Anweisungen scheinen auch schlicht nicht ausgeführt, 
sondern übersprungen, zu werden, alles ziemlich zufällig.

Herausgefunden, dass es (wohl) am nicht-casten einer Variable liegt, 
habe ich es durch Try&Error in einer früheren (kleineren) Version des 
Programms.

Nun ist es so, dass ich solche Fehler nur mit großem Aufwand finden 
kann, da ich keinen Debugger besitze und der Fehler im Simulator nicht 
auftaucht.

Einen solchen Fehler habe ich nun in meinem Programm und hätte gerne mal 
euren Rat, wie man soetwas leichter finden oder sogar ganz vermeiden 
kann (Compilerflag?).

Liebe Grüße
Sebastian

[Peter II (Gast)]

Sebastian schrieb:
> Wenn ich nun einer Funktion, welche einen uint32t als Parameter
> verlangt, beispielsweise einen uint16t übergebe, ohne ihn zu casten,
> meckert erstens AtmelStudio 7 nicht und zweitens, ich bekomme sehr
> merkwürdige, fast zufällige Ausfallerscheinungen:

dann liegt der Fehler woanders. Das ist ein normales Verhalten und muss 
funktionieren.

[eProfi (Gast)]

> Nun ist es so, dass ich solche Fehler nur mit großem Aufwand
> finden kann, da ich keinen Debugger besitze und der Fehler
> im Simulator nicht auftaucht.
Ganz einfach: Debugger kaufen oder bauen. Du wirst Dich fragen, warum Du 
das nicht schon vor Langem getan hast.

Weitere Tipps kann man kaum geben, weil wir Dein Programm nicht kennen.
Evtl. bringen Debug-Ausgaben etwas, entweder über seriell oder I/O.
Kommt auch stark darauf an, ob zeitkritisch etc.

[Harry L. (mysth)]

Sebastian schrieb:
> Ich habe ein recht umfangreiches C++-Programm auf einem Mega16 laufen

Schuss ind Blaue:
Da fällt mir direkt Heap- oder Stack-Überlauf ein...

[nicht"Gast" (Gast)]

schmeiß mal -Wall an. Dann sollte der Compiler schon meckern.

[Peter II (Gast)]

nicht"Gast" schrieb:
> schmeiß mal -Wall an. Dann sollte der Compiler schon meckern.

nein sollte er nicht. Es gibt nicht den kleinsten Grund g
für eine Warnung.

[nicht“Gast“ (Gast)]

Huch,
Da hast du Recht. Ich hab mich da verlesen. Ich dachte er schmeißt einen 
uint32  auf einen uint16 Parameter und hab mich schon gewundert, dass da 
kein Fehler kommen soll

[Kaj (Gast)]

Sebastian schrieb:
> Wenn ich nun einer Funktion, welche einen uint32t als Parameter
> verlangt, beispielsweise einen uint16t übergebe, ohne ihn zu casten,
> meckert erstens AtmelStudio 7 nicht
1. Es koennen maximal Compiler und Linker meckern
2. Warum glaubst du, dass da irgendwas meckern sollte?

Sebastian schrieb:
> fast zufällige Ausfallerscheinungen
Klingt nach Stack/Heap ueberlauf, und/oder einem wilden Pointer
bzw. Zugriffe auf nicht existente Arrayelemente, wodurch andere 
Variablen ueberschrieben werden.

Sebastian schrieb:
> wie man soetwas leichter finden
- Programmlogik und Zugriffe auf die Hardware sauber kapseln.
  Dann koenntest du deine Programmlogik recht einfach testen,
  z.B. durch Unittests.

- Debugger besorgen und debuggen.

Sebastian schrieb:
> oder sogar ganz vermeiden kann
Sich beim programmieren (noch besser davor!) Gedanken darueber machen, 
was man da eigentlich macht, und sauber arbeiten. Eine zweite Person 
drueber schauen lassen (Pair-Programming, Code-Review) koennte auch 
helfen.

Ansonsten Warnungen einschalten (-Wall -Wextra), Warnungen als Error 
behandeln (-Werror), damit du keine Warnung vergisst. Tools wie CppCheck 
helfen auch.

[Alex W. (a20q90)]

Zum Atmega16: hat der Abblockkondensatoren an den VCCs gegen GND?

[Sebastian (Gast)]

Hallo zusammen,

zunächst möchte ich sagen, dass ich mir durchaus VORHER Gedanken zu dem 
Projekt und dem Programm gemacht habe und da ich auch beruflich 
programmiere (C#) behaupte ich einfach mal, ich weiß schon in etwa, 
worauf es ankommt. :) Mikrocontroller (und auch ein bisschen C++) sind 
allerdings Neuland für mich und ich muss mich erst an die 
(Hardware-)Verhältnisse gewöhnen.

Nun zum Thema:
Ich vermute mittlerweile auch, dass es an einem Heap-/Stacküberlauf 
liegt, da alles einwandfrei läuft, wenn ich (zur Sicherheit 
verschiedene) andere, kleinere Programmteile auskommentiere und somit 
das Programm kleiner wird. Atmel Studio schreibt dazu:

Program Memory Usage   :  9910 bytes   60,5 % Full
Data Memory Usage   :  785 bytes   76,7 % Full
EEPROM Memory Usage   :  202 bytes   39,5 % Full

Ich habe jetzt mal nen Mega324PA bestellt und werde es dann dort testen.

Bin ich damit auf einem guten Weg, oder ist das eher Quatsch?

[Sebastian (Gast)]

Nach etwas lesen (soll ja oft helfen ;-)) habe ich noch eine Frage:

Kann es hier eventuell helfen, wenn ich einige Variablen als "volatile" 
deklariere, und sie somit nicht mehr im Stack, sondern im 
Programmspeicher liegen?

[Oliver S. (oliverso)]

Sebastian schrieb:
> Kann es hier eventuell helfen, wenn ich einige Variablen als "volatile"
> deklariere, und sie somit nicht mehr im Stack, sondern im
> Programmspeicher liegen?

Nein.

Oliver

[Dumdi D. (dumdidum)]

Mal alle Array Zugriffe überprüfen? Z.B. [] überladen und checks 
einbauen?

[Mark B. (markbrandis)]

Sebastian schrieb:
> Einen solchen Fehler habe ich nun in meinem Programm und hätte gerne mal
> euren Rat, wie man soetwas leichter finden oder sogar ganz vermeiden
> kann (Compilerflag?).

Finden kann man den Fehler wahrscheinlich durch statische Codeanalyse. 
Es gibt eine Menge verschiedener Tools dazu:

https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#C.2C_C.2B.2B

[Thomas H. (flaretom)]

Hallo,

Male doch mal den Stack an (Stack-canary) und prüfe, ob es wirklich 
einen Überlauf gibt. Den Heap kann man durch ein angepasstes malloc 
checken.

Schönen Ostermontag noch!

[Hubert G. (hubertg)]

Sebastian schrieb:
> Program Memory Usage   :  9910 bytes   60,5 % Full
> Data Memory Usage   :  785 bytes   76,7 % Full
> EEPROM Memory Usage   :  202 bytes   39,5 % Full

Wenn nur 239 Byte für Stack und Arbeitsspeicher übrig bleiben, darf man 
sich nicht wundern wenn es hakt.