merkwürdige Abstürze abhängig von Menge Programmcode

[BoGe-Ro]

Hallo Forum,

der Titel ist zugegebenerweise sehr verwirrend, aber das Problem ist folgendes:

Ich entwickel ein Program auf dem Savvy128 Controller Board von chip45.com.

Mitlerweile meldet der Bascom-Compiler: Flash used: 51%

seit ich etwa die 50%-Marke überschritten habe, treten sehr oft Programmabstürze im ATMEGA auf.

Wenn ich beispielsweise eine Function ans Programmende anfüge, sie ordentlich deklariere, compiliere und auf den Controller brenne, spinnt anschließend mein Programm auf dem Controller.
Es werden wild Ausgänge geschaltet - an denen wo Hardware hinterhängt, seh ich anziehende und abfallende Ventile, oder PWM-Ansteuerungen von Lüftern und Heizungen und über die serielle Schnittstelle sehe ich Statusmeldungen von Neustarts aller paar Sekunden.
Mein LCD-Display füllt sich auf allen Positionen mit einem Zeichen.

Dies alles geschieht, nur durch den zusätzlichen Code, es gab noch keinen Aufruf der function.


Ein anderes Bespiel:

Ich möchte Parameter, zur Anzeige auf das Display bringen. Ca. 20 Parameter, wobei jeweils ein Parameter und sein Variablenname auf dem Display abgebildet werden soll.
Ursprünglich eine Case-Auswahl, zwischenzeitlich zur Fehlereingrenzung 20 If-Then Anweisungen wo je nach gewählter Parameter-Nummer die zwei LCD-Anweisungen ausgeführt werden (Variablenname und Variablenwert)
Jedenfalls, habe ich die gesamt Sub im Programm, spinnt alles, wie oben beschrieben, grenze ich per Auskommentierung vielleicht 10 der 20 If-Then-Blöcke aus läuft es.

Ich möchte damit ausdrücken, dass funktionstüchtiger Programmcode, offensichtlich einfach durch sein Vorhandensein für diese Abstürze verantwortlich ist - und das bei einem Flash-use von ca. 50%.

Da das Programm aus sehr vielen Änderungen besteht, wobei alte Programmteile nicht mehr aufgerufen werden, helfe ich mir jetzt damit, dass ich beim Auftreten eines Fehlers solch alten Code Suche und lösche - mir damit Platz schaffe und somit dann auch an neuen Baustellen weiterkomme.

Aber der Fehler muss ja woanders liegen - wo kann ich noch suchen?
Wer hat ähnliches beobachtet - und vielleicht die Lösung gefunden?


besten Dank für kommende Lösungsvorschläge



BoGe-Ro

[Richard]

Möglich das du deinen Stack überschreibst, vergrößer den mal.

Gruß Richard

[Hubert.G]

Es kann aber auch sein das dir dein SRAM zu klein wird.
Ich kann kein BASCOM, aber in C legt man z.B. Anzeigen fürs LCD im PROGMEM ab oder im EEPROM.
20 Variablen-Namen fürs LCD sind gleich mal eine Menge Byte.
Wird beim Compilieren im Bascom nicht ausgegeben wie viel Platz im SRAM fest belegt ist?

[BoGe-Ro]

Hallo,

danke für Eure Antworten.

Ich habe die Stacks als auch die Angabe für Framesize erhöht (Stacks verdoppelt, Framesize auf 1,3fach) was beides keine Besserung brachte.
Getestet hab ich es an diesen If-Then-Blocks - also ganz sicher fehlerfreiem Code.

Zur zweiten Antwort: der SRAM-Speicherplatz wird während der Compilierung gegengecheckt - aus dem Grund hab ich auch die Angabe Framesize vom ursprünglich doppelten Wert bis auf den 1,3 fachen verkleinert - weil der Compiler mit "zu wenig SRAM" quitierte.

[Vitis]

müsste man den code sehen um wirklich was sagen zu können.

Aber solche Fehler kommen idR mit Frame SwStack HwStack.

Ich geh immer hin und verteile den freien ungenutzten SRAM komplett auf die Geschichte. seitdem gehts meist gut. Aber wie gesagt, ohne Code schwer zu sagen.

Ach so, eins hatt ich mal.

Wenn ich Subroutinen per gosub angesprungen habe war ab ner kritischen Menge ähnliches Verhalten.
Seit ich meine Unterroutinen in Sub packe und per call aufrufe ists besser.

[Felix H.]

Hi,

ich hatte auch ein phänomen mit folgendem Code:

Am Ende meines Programms hatte ich Bgf-Dateien für ein Display angehängt und direkt dahinter den "end" Befehl gesetzt. Immer wenn ich das letzte Bild, was direkt über dem end stand, aufgerufen habe waren extreme Pixelfehler auf dem Display zu sehen.

Vielleicht ist es bei dir ja auch etwas ähnliches.

[Willa]

Ich würds nochmal mit hwstack, swstack, framesize versuchen.... Habe auch die Erfahrung gemacht, dass Abstürze manchmal daran liegen. Und Faktor 1.3 ist vielleicht einfach noch nicht genug. Ich bin z.B. schon bei diesen haarsträubenden Werten angekommen (ohne wirklich zu wissen was ich da tue...):

'===Settings ===
$regfile = "m328pdef.dat"
$framesize = 512                                            'smaller than 128 => stops responding...
$swstack = 256
$hwstack = 128                                              '256
$crystal = 8000000
$baud = 38400

[Vitis]

da kann ich mit:

$regfile = "m128def.dat"                                    ' specify the used micro
$crystal = 14745600                                         ' used crystal rfm_Frequency
$baud = 38400                                               ' use baud rate

$hwstack = 400                                              ' default use 32 for the hardware stack
$swstack = 990                                              ' default use 10 for the SW stack
$framesize = 990

[wkrug]

Kürzlich hatte ich ein Problem in "C" mit überlaufenden indizierten Variablen.

Eine Variable war mit 20 Zeichen definiert.

unsigned char stoerer [20];
unsigned char gestoert=0;

im Programm wurde die Variable stoerer mit dem Wert 20 ( =der 21. Wert ) indiziert.

stoerer[20]=44;

Da dieser Speicherplatz allerdings nicht mehr der Variable stoerer zugewiesen war, wurde die Variable gestoert auf den Wert 44 gesetzt, was natürlich zu Problemen führt.

Eventuell hast Du bei Deinem Programm das gleiche Problem ?!

[Richard]

Ich würds nochmal mit hwstack, swstack, framesize versuchen.... Habe auch die Erfahrung gemacht, dass Abstürze manchmal daran liegen. Und Faktor 1.3 ist vielleicht einfach noch nicht genug. Ich bin z.B. schon bei diesen haarsträubenden Werten angekommen (ohne wirklich zu wissen

So weit mir bekannt kann man Bascom anweisen sehr ausführliche Logdateien beim Compilieren zu erstellen.
Dort sollte auch die Stack Auslastung zu finden sein.

Gruß Richard