www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Arm7 FreeRTOS Problem


Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich benutze folgenden Port: 
http://www.sirsydom.de/permalinks/MCB2300FreeRTOSlwIP.rar

auf einem Keil MCB2300 EvalBoard mit einem LPC2368.

Den ganzen Ethernet/IP Code habe ich entfernt und es läuft.

Nun füge ich hier und da etwas Code hinzu und nichts geht mehr. D.h. 
FreeRTOS läuft nicht mehr, es werden keine Tasks mehr geschedult.

Das ist völlig verrückt! Entferne ich 2 Zeilen Code aus einer Funktion 
die ich niemals aufrufe geht es nicht mehr, füge ich sie wieder dazu 
gehts wieder. Manchmal genau andersherum. Ich hab keine Ahnung wo ich 
anfangen soll das Problem zu lösen.

Autor: Schorschl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

schalte mal die compileroptimierung ab und schau dir ev. noch den 
generierten
assemblercode an. Hast du ev. noch den Watchdog aktiv?

gruss,
schorschl.

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Optimierung ist bereits aus.
Wenn du mir noch sagst was genau du mit Watchdog aktiv meinst kann ich 
es dir vielleicht auch sagen :)
Ich bin recht neu in dem ganzen Thema..
Und Assemblercode ansehen, naja sind ja doch einige kb wo soll ich da 
anfangen?

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In welcher Funktion entfernst du welchen Code? An welchen hier und da 
Stellen fügst du welchen Code hinzu? Ist in dem angegebenen 
Projektarchiv der lauffähige Fall oder der nicht-lauffähige Fall?

Aus dem MAP-File und dem Linkercontrolskript geht hervor, dass ein 0x800 
Bytes grosser Stack eingestellt ist. Du verwendest ausserdem ein 
Linkercontrolskript LPC2368_ROM.ld für ein Target LPC2378. Ist das 
Speicherlayout kompatibel?

Ohne obiges zu kennen, würde ich "probieren" den Stack hochsetzen und 
dann kucken, was der Ball macht. Im Moment hast du 0x800 (2 KB) brutto 
d.h. 0x400 netto + Rest Stack für Interrupts.

Zwischen Stack und RAM-Daten (DATA+BSS) ist noch 2732 Bytes Platz. Die 
könntest du wenigstens teilweise zur Stackerweiterung nutzen. Dafür wäre 
im Linkercontrolskript anzupassen:

Length bei ram kürzen (0x7800 => 0x7000)
Origin bei ramstack verschieben (0x40007800 => 0x40007000)
Length bei ramstack erhöhen (0x0800 => 0x1000) d.h. 100% mehr Stack



Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Linkcontrollskript für den 2368 ist auf jeden Fall korrekt weil es 
ein 2368 ist auf dem ich den code ausführe.

Danke für deine Hilfe, leider hat es nicht geholfen.

Du wolltest noch wissen welche Funktionen ich geändert habe:

Ich habe 3 Funktionen, LED_on, LED_off, LED_switch hinzugefügt (am Ende 
der main.c):

/*
void LED_switch(unsigned char num)
{

  if(num <= 7)
  {
    if(FIO2PIN & (1 << num) == (1 << num))
      FIO2SET = (1 << num);
    else
      FIO2CLR = (1 << num);
  }

}

void LED_on(unsigned char num)
{
  if(num <= 7)
    FIO2SET = (1 << num);
}

void LED_off(unsigned char num)
{
  if(num <= 7)
    FIO2CLR = (1 << num);
}
*/

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hinzugefügt inkl. Kommentarzeichen oder ohne? Die Funktionen werden, so 
weit ich dich verstanden habe, nur deklariert aber nie angesprungen.

Wie sieht die Map-Datei aus, wenn obiger Code hinzugefügt ist?

Wie sieht das Main-Listing aus, wenn obiger Code hinzugefügt ist?

Zum Erzeugen des Main-Listings (main.lst) das Makefile damit ergänzen:
CFLAGS += -Wa,-adhlns=$(subst $(suffix $<),.lst,$<)
# Beitrag "Listfile erzeugung mit GNUARM compiler"

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eventuell wird Fast IO und Legacy IO am Port2 gemischt. Das mögen die 
nicht.

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

ich hab mal mein Projekt, so wie es läuft, also mit auskommentierten 
LED-Funktionen gezippt: 
http://www.sirsydom.de/permalinks/FreeRTOS_LPC2368.zip

Die Listfiles und Mapfiles habe ich einmal mit und einmal mit 
auskommentierten LED-Funktionen erstellt:
http://www.sirsydom.de/permalinks/main.lst_mit
http://www.sirsydom.de/permalinks/LPC2378TEST.map_mit
http://www.sirsydom.de/permalinks/main.lst_ohne
http://www.sirsydom.de/permalinks/LPC2378TEST.map_ohne


@Werner

Eigentlich kann das nicht sein, des ist egal was ich in den Funktionen 
mache.

Definiere ich zb in der main.c diese Funktion:

void hfasdkue(void)
{
  int a;
  int b;
  int c;
  int d;

  a = 7;
  b = 9;
  c = 7*9%3;
  d = c*234;
  d /= 17;
}

geht es auch nicht mehr. Entferne ich diese - gehts wieder.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Listfiles habe ich einmal mit und einmal mit auskommentierten
> LED-Funktionen erstellt:
> http://www.sirsydom.de/permalinks/main.lst_mit
> http://www.sirsydom.de/permalinks/main.lst_ohne

Da ist was schief gegangen. Das sind nicht die Listings von main.c 
sondern von Startarm.s. Diese beiden Listings sind identisch.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> http://www.sirsydom.de/permalinks/LPC2378TEST.map_mit
> http://www.sirsydom.de/permalinks/LPC2378TEST.map_ohne

Haben nur einen temporären Dateinamen als Unterschied, d.h. am 
Speicherlayout hat sich durch die Änderung in main.c nichts geändert.

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm. Ich habe einfach die Zeile in mein Makefile geschrieben, so:

#
# CFLAGS common to both the THUMB and ARM mode builds
#
CFLAGS=$(WARNINGS)  -D GCC_ARM7 -I. \
    -I ./include \
    -I $(SOURCE_DIR) \
    -I $(RTOS_SOURCE_DIR) \
    -I $(RTOS_PORT_DIR) \
    $(DEBUG) $(CPU_TYPE) -T$(LDSCRIPT) \
    $(OPTIM)

ifeq ($(USE_THUMB_MODE),YES)
  CFLAGS += -mthumb-interwork -D THUMB_INTERWORK
  THUMB_FLAGS=-mthumb
endif

CFLAGS += -Wa,-adhlns=$(subst $(suffix $<),.lst,$<)


>Haben nur einen temporären Dateinamen als Unterschied, d.h. am
>Speicherlayout hat sich durch die Änderung in main.c nichts geändert.

Das heißt? Das es daran nicht liegt?

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> main.lst aus startarm.s statt aus main.c ...

Ich sehe die Ursache im Moment nicht und kann das heute abend selbst 
testen. Irgendwas läuft im Makefile anders als gedacht. In dem Makefile 
aus deinem letzten Archiv ist die Zeile übrigens nicht drin - benutzt du 
das richtige Makefile?

> Kein signifikanter Unterschied im .map File ...

Der .map Filevergleich zeigt, dass das Problem irgendwo anders liegt als 
im Speicherlayout.

Interessant ist, ob der Compiler mit/ohne Zusatzzeilen (Kommentar) 
andere Code-Listings erzeugt. Aber wenn das Speicherlayout (Adressen, 
Längen, Namen) bereits identisch ist, passt das dort wahrscheinlich auch 
;-(

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In dem Makefile
>aus deinem letzten Archiv ist die Zeile übrigens nicht drin - benutzt du
>das richtige Makefile?

Die habe ich eingefügt nachdem ich das Projekt gezippt hatte, ohne wurde 
kein main.lst erzeugt.

Auf jeden Fall mal Danke für deine Hilfe.

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann keinen essentiellen Unterschied zwischen der Version mit den 
auskommentierten Zeilen in main.c und ohne diese Zeilen entdecken.

Allerdings hat mich die Sache mit dem falschen Listing stutzig gemacht 
und der bin ich solange nachgegangen bis es korrekt gemacht wird.

Dabei ist ein geändertes Makefile entstanden (s. Anhang). Die 
Assemblersource ist jetzt nicht "einfach" in der finalen Build-Regel 
aufgeführt, sondern hat einen eigenen Regelsatz bekommen.

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich bins wieder, nun bin ich etwas weiter gekommen!

Ich weiß nun das ich im DAbt_Handler lande, weil wohl irgendwo auf eine 
falsche Adresse zugegriffen wird.
Dies passiert auf jeden Fall nachdem die Task gestartet wurde, und wie 
es scheint wird auch jeder Task einmal aufgerufen.

Aber irgendwie spinnt mein GDB noch ziemlich, ich komm da nicht weiter. 
Ich komme nie bis zu der Stelle an der der DAbt zuschlägt.
Evtl hat ja jemand DIE zündenen Idee :)

Autor: Dirk (barricade) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1.) BP auf 0x10 DAbt setzen

2.) Dabt zuschlagen lassen

3.) Fehlerstelle suchen mit Unassemble R14-8

4.) BP auf Fehlerstelle setzen

5.) Reset & Run, usw.

Gruß Dirk

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bin wieder mal etwas weiter gekommen, uA hab ich die Quelle des DAbt 
gefunden: Die ist je nach Code immer mal woanders - völlig 
undeterministisch.

Was ich aber herausgefunden habe und ich mir überhaupt nich erklären 
kann:
Ich hab nach dem Setup der MAM mal ein paar NOPs eingefügt (war ein 
Tipp). Dabei bemerkte ich folgendes:
Bei 6, 7, 10, 11, und 14 NOPs bekam ich einen DAbt
Bei 8, 9, 12 und 13 NOPs lieg alles wie geschiert!

Was zum Teufel kann das sein???

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

mit welcher Frequenz taktest du den LPC denn? In der LPC2000 Yahoo Group 
gab es mehrere Berichte wonach bestimmte LPC23xx bei höheren Taktraten 
nicht-deterministische Fehler aufweisen.

Auch scheinen Probleme mit dem LPC23x stark vom Produktionszeitpunkt 
abzuhängen - welcher Datecode steht denn auf deinem Chip?

Gruß,

Dominic

Autor: Sir Sydom (sirsydom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab 2 Keil MCB2300, ich takte mit 72MHz über 12MHz XTAL.
Date Code schaut aus wie ZSG0701-Y (also KW1 2007 ? Na toll, ein 
Neujahrsprozessor :) schlimmer als jedes Montagsauto lol)

Ich probiers mal mit 4MHz und schau was passiert.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Angeblich sollen kein Problem auftreten, wenn der Prozessor mit bis zu 
48MHz getaktet wird. Der letzte Thread zu dem Thema hatte den Titel 
"[lpc2000] Investigation of LPC23xx MAM Issues"

Gruß,

Dominic

Autor: Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salü!

Gleich mal sorry vorweg: ich habe den Thread nur diagonal durchgelesen. 
Vielleicht macht meine Antwort also hier keinen Sinn.

Deine Aussage :"manchmal auch umgekehrt" machte mich stutzig. Könnte es 
sein, dass es gar nicht an diesen zwei Zeilen liegt?

Ich hatte nämlich bei meinem STM32 ein ähnliches Problem: Plötzlich lief 
nichts mehr, dann irgendwann mal ein "altes" Design geladen, dann war's 
ok, dann das neue wieder drauf, lief auch, dann später nochmals 
probiert, nichts ging, das alte auch nicht mehr, dann plötzlich doch 
wieder...


Die Lösung war ganz einfach: Bei meinem Linkerscript-File hat sich ein 
Fehler eingeschlichen. Der Stack-Pointer (der beim Cortex nach Power-up 
von Adresse 0x0 initialisiert wird), zeigte ins Nirvana.

Wenn ich also das alte Design startete, initialisierte er korrekt. Dann 
flashte ich das neue Design, und es lief. Dann irgendwann probierte ich 
es wieder (power-up) und nichts ging. Dann flashte ich das alte Desing 
-> lief auch nicht, dann, nach einem Reset, plötzlich schon wieder....

Vielleicht ist das ja das Problem...

Gruss
Simon

Autor: Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheisse, ich sollte zuerst mal das Datum anschauen..... ups... 
soooorrrryyyy!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.