Hallo, Für meine Studienarbeit programmiere ich gerade einen C164 mit uVision von Keil und komme einfach nicht weiter. Ein Programm, dass absolut unverändert schon in dieser Konfiguration gelaufen ist (und auch nicht sehr groß ist) bringt mir beim Compilieren Linkerfehler wie "Memory Overlap at 0x0008 to 0x0004". Mir ist zwar klar klar, was diese Medlung bedeutet, aber der Code ist in C und besteht aus nichts außer ein paar globalen Variablen und 3 kleinen Funktionen inkl. main. Ich dachte, gerade dafür is die IDE doch da, dass ich mir um die absoluten Adressen keine Gedanken machen muss. Außerdem ist im Linkerfile der Bereich von (etwa) 0x06 bis 0x0FFF schon standardmäßig reserviert (umfasst jedenfalls alle Speicherbereiche, bei denen Overlap als Fehler angegeben ist). Kann doch was nicht stimmen, oder? Da es am Code nicht liegen kann (hab ihn trotzdem mal mit hochgeladen) lautet meine Frage: Gibt es für's Debuggen auf dem µC wichtige Grundeinstellungen im Projekt an denen so etwas liegen könnte? Woran könnte es überhaupt noch liegen? Bei Bedarf kann ich (allerdings erst Dienstag) die Fehlermeldungen auch genau zitieren. Vielen Dank im Voraus an alle, die sich die Mühe machen, darüber nachzudenken und Grüße, Jan B.
Da müsstest Du mal Dein Linkerfile und das *.M66 File posten...
Okay, dann mal los. Wenn ich automatisch linken lasse (was meiner Meinung nach eigentlich reichen müsste, da die IDE weiß, dass es ein C164CI auf einem SYSTEC DIPModul ist), kommen diese zwei Warnungen: *** WARNING L22: CLASS RANGE NOT GIVEN IN INVOCATION LINE CLASS: NCONST *** WARNING L5: SECTION LOCATED OUTSIDE CLASS AREA SECTION: ?C_USERSTACK CLASS: NDATA ---------------------------------------------------------------- ---------------------------------------------------------------- Nu mit externem Linkerfile_ ---------------------------------------------------------------- Drin steht Folgendes: ECTIONS(?C_STARTUP_CODE%ICODE (0x01000), ?C_INITSEC (0x01150)) CLASSES(ICODE (0x000200-0x003FFF) , FCODE (0x000200-0x003FFF), NCONST (0x000200-0x003FFF) , FCONST (0x000200-0x003FFF), NDATA (0x060000-0x061FFF) , NDATA0 (0x060000-0x061FFF), FDATA (0x060000-0x061FFF) , FDATA0 (0x060000-0x061FFF), HDATA (0x060000-0x061FFF) , HDATA0 (0x060000-0x061FFF), XDATA (0x060000-0x061FFF) , XDATA0 (0x060000-0x061FFF)) RESERVE(0x04-0x01FF, 0xE000-0xF9FF, 0xFC20-0xFFFF, 0x03EB00-0x03ECB8, 0x03ED00-0x03FEE2) Und die M66 hab ich angehängt.
Vorsichtshalber gleich mal noch die Fehlermeldungen beim Linken mit externem Linkerfile dazu: Build target 'DIPModul 164' linking... *** ERROR L114: SECTION DOES NOT FIT WITHIN SEGMENT BOUNDARY SECTION: ?BI0?STROMMESSUNG CLASS: BIT0 *** ERROR L107: CLASS ADDRESS RANGE OVERFLOW SECTION: ?BI0?STROMMESSUNG CLASS: BIT0 *** WARNING L4: MEMORY SPACE OVERLAP FROM: 00008CH.0 TO: 000090H.0 *** WARNING L4: MEMORY SPACE OVERLAP FROM: 0000A0H.0 TO: 0000A4H.0 *** ERROR L119: REFERENCE MADE TO ERRONEOUS SECTION SECTION: ?PR?STROMMESSUNG CLASS: FCODE MODULE: strommessung.obj (STROMMESSUNG) ADDRESS: 0DC2H Program Size: data=4148(near=4132) const=176(near=176) code=3264 Target not created Nur vorsichtshalber, und nur weil es nur 68 KB groß ist, hab ich mal noch das ganze Projekt als rar angehängt, falls jemand die Projekteinstellungen nachvollziehen will. Gruß, Jan
1.) mit RESERVE(0X04-0X01FF, ...) wird ein Speicherbereich Reserviert von Adresse 00004h bis 001FFh das ist die Interrupt-Vektortabelle (ausgenommen dem Reset-Vektor) dies Beisst sich auf jeden fall mit den 2xInterrupts die definiert wurden => MEMORY SPACE OVERLAPPED => Abhilfe: Reserve() anpassen. 2.) Es gibt eine "BIT"-Variable OneChannel die eigentlich in dem internen RAM liegen müßte => dieser ist aber per "RESERVE()" belegt dadurch kann die variable nirgends hingelegt werden => ERROR L114: SECTION DOES NOT FIT WITHIN SEGMENT BOUNDARY => CLASS ADDRESS RANGE OVERFLOW => Abhilfe (siehe oben) Gruss
Nachtrag: Sei so gut und klemm im Linker-File die Zeile mit dem RESERVE (die letzte Zeile) per Semikolon, dann läßt sich dein Programm compilieren ;RESERVE(... Gruss
Hmm, ich dachte, dass er aus genau diesem Bereich reserviert (darunter hab ich verstanden, dass dort keine Variablen aus dem Programm etc. abgelegt werden) sein muss. Vielen Dank erstmal, ich werde das am Dienstag probieren (Montag ist bei uns Feiertag, juuchhuu :D ). Gruß, Jan
Bin völlig baff - funktioniert einwandfrei, auch im Debug-Modus. uVision bringt zwar beim Verbinden zum µC immer noch die Fehlermeldung, dass der Inhalt der Adresse 0x0008 überschrieben wird, weil der "Monitor" die benutzt (weiß da jemand was drüber?), aber ansonsten läufts's problemlos. Vielen Dank :) Gruß, Jan
ICH WERD' HIER WEICH! Dieses C164-Vieh bringt mich zur Weißglut. Das exakt gleiche Projekt, das gestern funktioniert hat, hängt sich heute im Debug-Modus auf, sogar obwohl ich den 0x0008-Fehler behoben habe. Nach "Run", kommt das Programm nichtmal zur ersten Zeile der main() (-> Breakpoint), sondern führt ewig den zum Modul mitgelieferten Startup-Code (START164.A66) aus. Zumindest vermute ich das, weil ich bei Abbruch (per x-Button) im Disassembly-Fenster immer einen gelben Pfeil vor irgendwelchen Befehlen aus diesem Programmteil sehe. Woran kann es denn liegen, dass der µC einen einwandfreien Code (immerhin von KEIL) so falsch ausführt? (nach jedem Go+Stop ist der Pfeil vor einer anderen Zeile, also rührt der wohl wirklich in dem Code rum und hängt sich nicht immer an einem bestimmten Beefehl auf). Verzweifelt-wütende Grüße, Jan
>Nach "Run", kommt das Programm nichtmal zur ersten Zeile der main()
(-> Breakpoint), sondern führt ewig den zum Modul mitgelieferten
Startup-Code (START164.A66) aus.
Im Fenster 'Option for Target' das Häckchen bei 'Run to Main'
gesetzt?
Nein, hab ich nicht. Es macht aber auch keinen Unterschied :( Das Verrückteste ist ja mal: ich habe gerade in JEDER beteiligten Datei (strommessung.c , START164.A66, spaßeshalber sogar in den Header-Dateien) direkt am Anfang einen Breakpoint gesetzt -> Ergebnis wieder das gleiche, er läuft los, macht aber gar nichts und kommt zu keinem Breakpoint. Ich lade das aktuelle Projekt (mit korrigiertem 0x0008-Fehler) nochmal hoch, vielleicht hat ja jemand anders zufällig auch ein DIPModul rumliegen und kann schauen, ob es bei ihm/ihr das gleiche ist. So langsam würde ich die Schuld gerne auf ein kaputtes Modul schieben, die Fehler sind von tag zu Tag einfach zu zufällig ;)
Hat keiner eine Idee? (sorry, um den Fred nochma in die "Last 10"-Liste zu bringen)
Auch hier habe ich wieder das Bedürfnis, das Thema zu Ende zu führen, damit spätere Generationen [ ;) ] mit vielleicht demselben Problem Hilfe finden (mir selber wurde hier bisher ja auch sehr gut geholfen): Es scheiterte an der fehlenden Initialisierung der seriellen Schnittstelle, die für die printf() gebraucht wurde, um im Debug-Modus Ausgaben des µC auch auf dem Rechner sehen zu können (im Serial Window). Was mir bislang überhaput nichtklar ist, ist wieso das bei dem Projekt meines Nachbarn und noch jemandes aus dem Pc-Pool, in dem ich arbeite, einfach NICHT nötig war--- Die haben die Funtkion einfach benutzt un es lief, bei mir hat er sich aus unerfindlichen Gründen im StartUP-Code aufgehangen Schulterzuck Sobald ich diese Zeilen, gefunden im KEIL-Forum, in die main() einfüge, läufts einwandfrei: #ifndef MCB167 /* do not initialize if you use Monitor-166 */ P3 |= 0x0400; /* SET PORT 3.10 OUTPUT LATCH (TXD) */ DP3 |= 0x0400; /* SET PORT 3.10 DIRECTION CONTROL (TXD OUTPUT) */ DP3 &= 0xF7FF; /* RESET PORT 3.11 DIRECTION CONTROL (RXD INPUT) */ S0TIC = 0x80; /* SET TRANSMIT INTERRUPT FLAG */ S0RIC = 0x00; /* DELETE RECEIVE INTERRUPT FLAG */ S0BG = 0x40; /* SET BAUDRATE TO 9600 BAUD */ S0CON = 0x8011; /* SET SERIAL MODE */ #endif Grüße, Jan B.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.