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.
hi, schalte mal die compileroptimierung ab und schau dir ev. noch den generierten assemblercode an. Hast du ev. noch den Watchdog aktiv? gruss, schorschl.
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?
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
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);
}
*/
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"
Eventuell wird Fast IO und Legacy IO am Port2 gemischt. Das mögen die nicht.
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.
> 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.
> 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.
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?
> 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 ;-(
>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.
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.
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 :)
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
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???
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
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.
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
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
Scheisse, ich sollte zuerst mal das Datum anschauen..... ups... soooorrrryyyy!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.