GCC/newlib für M16C/62P: Keine Funktionsaufrufe möglich?

[kpeter (Gast)]

Hallo zusammen

Ich habe hier ein Board mit einem Mikrocontroller vom Typ Renesas 
M16C/62P vor mir liegen. Das Flashen des Programms funktioniert 
einwandfrei.

Mein Problem liegt allerdings darin, dass ich aus meiner main()-Funktion 
keine andere Funktionen aufrufen kann, zumindest wird nicht korrekt in 
die aufrufende Funktion zurückgesprungen.

Hier mein Minimalbespiel:

void test() {
    unsigned int i=10000;
    while(--i > 0) {}
}

int main() {
    unsigned int i = 0;

    PD6_4 = 1; // LED0
    PD8_7 = 1; // LED1

    P6_4 = 1;
    P8_7 = 1;
    
    test();

    while (1) {
        while (i++<9500) {}
        test(); // -> LED leuchtet dauerhaft (P8_7=0 wird nicht erreicht)
        P8_7=1;
        while (i++<10000) {}
        P8_7=0;
        i=0;
    }

    return 0;
}

Lösche ich die markierte Zeile, funktioniert das Programm einwandfrei.

Zur Kompilierung verwende ich folgenden Befehl:

m32c-elf-gcc -Wall -mcpu=m16c -o ledtest.elf main.c

Hat jemand eine Idee woran das liegen könnte?

Vielen Dank für eure Hilfe.

Grüsse
Peter

[(prx) A. K. (prx)]

Wie wird in dieser Umgebung der Stack definiert? Wenn der im Wald steht, 
dann wäre so ein Verhalten gut möglich.

[kpeter (Gast)]

Mein GCC habe ich mit newlib* (welche ihrerseits libgloss einschliesst) 
kompiliert. Somit müsste der Stack durch libgloss gesteuert werden. Ich 
habe aber diesbezüglich fast keine Erfahrung. Wie kann ich das 
herausfinden?

Wenn eine andere Konfiguration einfacher zum Ziel führen würde, kann ich 
auch gerne umstellen.

* http://sourceware.org/newlib/

[isio (Gast)]

Für den Code brauchst Du weder eine newlib noch eine libgloss.

Es wäre interessanter, Du würdest Deinen Startup-Code und
Dein Linker-Command File zeigen...

[Johann L. (gjlayde)]

Von der libgloss wird doch zumindest crt0.S verwendet, oder nicht?

Die Frage ist, ob newlib / libgloss richtig generiert wurden und zum 
Compiler und dessen multilib layout passen.

Ein Problem mit dem Code sind zudem die unsinnigen Warteschleifen, die 
komplett wegoptimiert werden können.  Damit wird die LED sehr schnell 
zwischen an / aus hin- und hergeschaltet und es sieht so aus, als würde 
sie immer brennen.

[Olaf (Gast)]

> Hat jemand eine Idee woran das liegen könnte?

Ich hab mal eine Gegenfrage. Wie kann eigentlich irgendjemand auf die 
Idee kommen Programme in C fuer eine Microcontroller zu schreiben ohne 
das man sich mit Linkerscript und Startupcode beschaeftigt?
Ich meine man muss die doch fuer jedes seiner Projekte anpassen. Es gibt 
ja gerade auch die M16C mit unterschiedlichen Ram/Flash. Und selbst fuer 
denselben Controller koennen die unterschiedlichens Werte notwendig 
sein. (z.B Bootloader ja/nein)

Du brauchst also ein Linkerscript das den Speicherausbau deines 
Prozessors beschreibt und ein Startupcode der damit etwas anfangen kann.

Zur Inspiration mal die beiden Dateien aus einem meiner Projekte. Du 
musst sie aber anpassen!

Olaf

p.s: Aber schoen zu sehen das noch einer den 62P nutzt. :-)

[(prx) A. K. (prx)]

@Olaf:

Ist das nicht ein etwas hinterfotziger Weg, R0L mit 0 zu laden?
   mov.b #%hi8(__bssstart),r0l

Und bei "set user stack pointer" wird nicht der USP sondern der der ISP 
gesetzt (U=0 ab Reset). Womit sich auch der nächste Kommentar erledigt.

[Olaf (Gast)]

> Ist das nicht ein etwas hinterfotziger Weg, R0L mit 0 zu laden?

Kann ich dir jetzt auch nicht sagen. Ich hab das auch nur uebernommen 
und etwas angepasst und die M16C nie in Assembler programmiert.

Olaf

[(prx) A. K. (prx)]

Das war eine rhetorische Frage. BSS liegt stets im RAM und das liegt bei 
den M16C stets in den ersten 64KB. R0 wiederum enthält bei SSTR keine 
Adresse, sondern die zuschreibenden Daten. Korrekt wäre es also, R0L 
direkt mit 0 zu laden, statt mit einem Adressteil, der stets 0 ist.

[Johann L. (gjlayde)]

Den Adressteil zu verwenden ist aber erklärender als eine magische 
Konstante wie "0".  Ok, selbst in Assembler gibt es auch Kommentare 
dafür :-)

[(prx) A. K. (prx)]

Johann L. schrieb:
> Den Adressteil zu verwenden ist aber erklärender als eine magische
> Konstante wie "0".

Andersrum. R0 enthält den zu schreibenden Wert, nicht den oberen Teil 
einer Adresse. Den Adressteil zu verwenden ist also gerade der falsche 
Weg und die Konstante 0 der richtige. Immerhin handelt es sich um jenes 
Codefragment, das BSS auf 0 setzen soll. Die "magische" 0.

Was oben steht entspricht in C formuliert ungefähr

  memset(lo16(__bssstart), hi8(__bssstart), __bsssize);

statt

  memset(__bssstart, 0, __bsssize);

und das funktioniert nur deshalb, weil hi8(__bssstart) immer 0 ist. hi8 
sind die Bits 16..23 (hoffentlich, sonst ...).

Korrekt wäre also

;; Loeschen der Variablen
          mov.b #0,r0l
          mov.w #__bssstart,a1
          mov.w #__bsssize, R3
          sstr.b

[kpeter (Gast)]

Besten Dank für eure zahlreichen Beiträge!
Ich werde mir Olaf's Linker-Script mal zu Gemüte führen. Allerdings muss 
ich mich hier noch komplett in die Materie einlesen, da mir diese Arbeit 
bisher abgenommen worden ist.

Mittlerweile funktioniert der Stack jedoch (bis jetzt zumindest) 
einwandfrei. Momentan versuche ich noch herauszufinden welche magische 
Änderung dies bewirkt hat (hatte mit zahlreichen Startup-Codes, 
Linker-Scripts und Compiler-Flags experimentiert).

Sobald neue Fragen auftauchen, melde ich mich gerne wieder.

Schöne Weihnachten und erholsame Feiertage,
Peter