Forum: Mikrocontroller und Digitale Elektronik Programm läuft ab bestimmter Codegröße nicht mehr (AT-MEGA / Arduino programmiert mit mikroPascal)


von Roland K. (Firma: KEC GmbH) (rkretschmer)


Lesenswert?

Ich entwickle und programmiere aktuell eine DALI-Ansteuerung mit einem 
ATmega 328P. Als Testboard verwende ich ein Arduino Uno.
Programmierung läuft über mikroPascal Pro for AVR (freie Version - bis 
2000 Worte) - upload auf das Board über avrdude.
Eigentlich eine tolle Kombination.

Der Programm-Teil, der die DALI-Befehle sendet, funktioniert auch.
Ich muss ihn aber noch erweitern.
Jetzt das Problem: Sobald das Programm eine Code-Größe von ca. 1040 Byte 
erreicht, kann ich die HEX-Datei zwar über avrdude hochladen, aber es 
läuft nichts mehr.

Ich habe, um herauszufinden, woran das liegt, dem funktionierenden 
Programm eine eigentlich nicht notwendige Variable hinzugefügt und 
belegt und nichts tut mehr.
Dann eine weitere Variable, die den Code vergrößert, und es läuft 
wieder.

Bei weiteren Variablen läuft es wieder nicht.

Hat jemand ähnliche Erfahrungen gemacht oder weiß jemand, woran das 
liegen könnte.

Danke schon einmal
Roland

von Wolfgang (Gast)


Lesenswert?

Roland K. schrieb:
> Hat jemand ähnliche Erfahrungen gemacht oder weiß jemand, woran das
> liegen könnte.

Vielleicht liegt es an deinem Speicher. Beim Laufen des Programms wird 
nicht nur Flash-Speicher benötigt. Wie geht es deinem Stack und deinem 
RAM?
"Es läuft nichts mehr" ist als Diagnose etwas dünn.

von Lotta  . (mercedes)


Lesenswert?

Wolfgang meinte:
> "Es läuft nichts mehr" ist als Diagnose etwas dünn.

Recht hatter!! :-P
Was ist das für ne Variable? Ne statische oder ne dynamische?

Ich kenn micropascal nicht. Aber Pascal hat die Eigenschaft
bei zu kleinem Stack zu spinnen.
Schalte den Stackcheck ein! Vergrößere den bereitgestellten
Stack in der zugelinkten Startupdatei des Linkers, dort wird auch
die RAM - Größe festgelegt! Stimmt das eingestellte Speichermodell,
erkennt der Compiler wirklich den vorhandenen Speicher?
Ist vielleicht ein falscher Chip (Device) mit weniger Speicher
eingestellt?

mfg

: Bearbeitet durch User
von Roland K. (Firma: KEC GmbH) (rkretschmer)


Lesenswert?

Danke an Wolfgang und Lotta für die konkreten Hinweise.

"Tut nicht mehr" bedeutet:

Das Programm soll - wenn es tut - einen PIN ein- und ausschalten und 
damit ein Signal in Manchestercodierung erzeugen. Taktzeit 416 us.

Das funktionierte zunächst nicht. Ich habe das Programm dann auf die 
wesentliche Grundfunktion eingedampft.

Jetzt funktioniert es korrekt und das kann am Oszilloskop beobachtet 
werden. Das Signal wird über eine entsprechende Hardware auch von den 
Bus-Teilnehmern korrekt erkannt.

Jetzt muss dieses "hello world" erweitert werden.
Und das führt dazu, dass das Signal komplett weg ist.

Der Unterschied zwischen "tut" und "tut nicht" besteht z.B. in folgender 
(sinnfreier) Ergänzung:

var
K: byte;
Ergänzung im Hauptprogramm:
K:=1;

ohne Einfluss auf das restliche Programm, da die Variable sonst nicht 
weiter genutzt wird.

Anscheinend bin ich mit dem eingedampften Programm jetzt zufällig knapp 
unterhalb einer Grenze gelandet.

Das lauffähige Programm hat als Variablen lediglich:
13 x sbit:  Input_xyz bzw. Output1: sbit at Pin_...
9  x Byte   für Daten und Schleifenindizes

Da hatte ich eigentlich noch keine Begrenzungen erwartet.
Habe mich bislang allerdings tatsächlich noch nicht mit den 
Compilereinstellungen befasst.
Da werde ich dann wohl nicht dran vorbei kommen ;-).

Danke erst einmal und ein schönes Wochenende ...

von Matthi (Gast)


Lesenswert?

Vielleicht weit her geholt, aber:
Ich hatte mal einen (zugegeben recht alten) Microcontroller auf einem 
Testboard der ein ähnliches Verhalten zeigte. Code lief, und wenn man 
irgendwo was hinzufügte oder weg lies, dann plötzlich nicht mehr.
Nach vielen Stunden suchen kamen wir zu dem Schluss das das RAM defekte 
Zellen hatte die sich nicht mehr verändern ließen. Der entscheidende Tip 
war das wir die selbe HEX file auf dem alten Controller nicht in die 
Gänge bekamen aber auf einem neuen Board alles prima lief. Danach haben 
wir im Compiler Output festgestellt das es sich um immer die selben 
Addressen handelte die Probleme verursachten.
Der Microchip Controller um dens hier geht war allerdings mehr als 10 
Jahre alt und wurde sehr massiv als R&D PCB gebraucht

von Roland K. (Firma: KEC GmbH) (rkretschmer)


Lesenswert?

So, inzwischen hat sich herausgestellt, dass das Programm bei nicht ab 
einer bestimmten Größe abschmiert, sondern bei einer bestimmten Größe.
Ich konnte dem Programm jetzt noch mehrere sinnfreie Variablen, 
Schleifen und Timeraufrufe hinzufügen und es läuft.

Zu RAM und Stack kann ich in meinem Compiler auf den ersten Blick nichts 
einstellen - da werde ich mich wohl noch mal in die Materie einarbeiten 
müssen.

Ich denke, ich werde Matthis Hinweis (danke dafür) mal nachgehen und ein 
anderes Board verwenden.

von Roland K. (Firma: KEC GmbH) (rkretschmer)


Lesenswert?

Problem (nicht) gelöst :-)

Es lag nicht am Board. Auf einem 2. baugleichen neuen Board traten 
dieselben Fehler auf.
Zum laufenden Programm eine sinnfreie Variable ergänzt: Absturz
Eine weitere sinnfreie Variable ergänzt: Alles läuft, wie es soll ...

7 hintereinander gestellte Wartebefehle funktionieren, das Ganze in 
einer Schleife stürzt ab.

Da nützt mir die schönste PASCAL-toolchain nichts :-(

Die Lösung des Problems bestand letztlich darin, mich endlich einmal in 
C einzuarbeiten und das Ganze dann mit dem MICRO-Chip-Studio zu 
programmieren.

Jetzt läuft es ...
                     ... und für die Abstürze zwischendurch, war nicht
                     der Compiler sondern ich selber verantwortlich.

Danke für´s mitdenken.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.