Leider bin ich da nun etwas überfragt was den Fehler betrifft. Für mich
scheint es so zu sein, dass es sich um ein Speicherplatz Problem
handelt.
Wie müsste ich im Linker Skript den Bereich vergößern?
Leon schrieb:> 5732-ff7f
==0xA84D
Dein CODE Segment will 0xA868 gross sein; da fehlen 0x1A Bytes (s.o.).
So weit so gut.
In der IAR WB gibts bei mir (ARM 9.10.2) einen Bereich
Options->Linker->Config:
Dort im Linker configuration file "Memory Regions".
Ich kann leider nicht beantworten, warum da bei Dir diese krummen
0x5732-0xff7f stehen; ich kenne aber auch den MSP430 nicht und Deine
IAR-WB Version.
VG, Stephan
Leon schrieb:> // Persistent memory (FRAM): 04400-0FFFF
Hmm, platz wäre ja also von da bis dort.
Da wo in deinem LinkerKonfigFile 0x5732 steht, einfach mal ein 0x5700
draus machen; mehr als nicht funktionieren kann es ja nicht;)
Da wir aber nicht wissen, was und warum zwischen 0x4400 und 0x5732
steht, bleibt die Diagnose schwammig…
dll schrieb:>> // Persistent memory (FRAM): 04400-0FFFF>> Hmm, platz wäre ja also von da bis dort.> Da wo in deinem LinkerKonfigFile 0x5732 steht,
Das 0x5732 steht gerade nicht im Linker-Skript; laut Fehlermeldung ist
das die Adresse, ab der gerade noch etwas frei ist.
Änderungen im Linker-Skript beeinflussen nicht die Anzahl der Bytes, die
der Mikrocontroller wirklich speichern kann. Soweit ich sehe, ist die
einzige Möglichkeit, den Code zu verkleinern.
Clemens L. schrieb:> das die Adresse, ab der gerade noch etwas frei ist.
Jupp; das fragt ich aber gaaanz oben schon: was ist zwischen 0x4400 und
0x5732? Und: natürlich KÖNNTE 0x5732 auch im LinkerKonfigFile stehen...
(z.B. weil der Bereich davor als "Ablage" verwendet wird - ist ja ein
FRAM, kein Flash/ROM)
Egal was es ist: entweder das unbekannte BLOB zwischen 0x4400 und 0x5732
kann kleiner oder der CODE muss (wieder) kleiner; die paar Byte wären ja
sicher kein Problem.
Hallo,
Wenn das FRAM des unbekannten MSP430 bei 0x4400 anfängt, dann sollte der
Linker da am Anfang die Konstanten platzieren, dann den Startup-Code und
anschließend die Applikation.
Die Fehlermeldung deutet darauf hin, dass bis zu Adresse 0x5732 alles
glatt geht (z.B. Konstanten + Startup-Code) und der nächste Block (z.B.
die Applikation) passt dann nicht mehr in die verbleibenden Bytes.
Die krumme Endadresse von 0xFF7F müsste ganz am Ende vom *.xcl
aufgeschlüsselt sein, weil da so Sachen wie JTAG Signatur, BSL Signatur,
... des MSP430 liegen sollten.
Darf man fragen, welche Version der IAR Embedded Workbench für den
MSP430 und welcher MSP430 genutzt werden?
Gruß,
Michael
Ähm du hast da was falsch im Config (Entweder im IAR Config) oder im
Programm selbst (eher warscheinlich)
So wie es aussiht ist der Platz für die Interrupts schon vergeben.
Fragen:
1.) Welchen MSP430FRxxx verwendest du ?
2.) Software in "C" oder Assembler ?
3.) Wie sieht das Init deiner Software aus?
4.) Wie sieht deine Interrupt Config im Programm aus?
Beispiel?
Oder Kompletes Programm mal anhängen.
Dan kann dir Geholfen werden ;-)
Beispiel:
Es gibt bei manchen MSP430 die Möglichkeit, Teile des Information Memory
für Code oder Konstanten zu nutzen:
https://www.iar.com/knowledge/support/technical-notes/general/placing-code-in-the-msp430-information-memory/
Laut Fehlermeldung fehlen gerade mal 0x1a Bytes und da könnte der in der
Tech-Note beschriebene Ansatz eine Möglichkeit sein.
Alternativ könntest Du auch (sofern noch nicht geschehen) die
Optimierung des Compilers für einzelne Files erhöhen und schauen, ob
dadurch die nötigen Bytes eingespart werden können.
Gruß,
Michael
Hallo,
mit dem *.xcl des MSP430FR5949 aus dem Installationsverzeichnis der IAR
Embedded Workbench erhalte ich bei einem Beispielprojekt eine
Platzierung von CODE sowohl in 0x4400-0xFF7F, als auch in
0x10000-0x13FFF:
1
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
Hallo,
im Anhang ein "quick'n'dirty" Beispiel, bei dem auch der obere
Speicherbereich ab 0x10000 genutzt wird, ohne was spezielles im Projekt
eingestellt zu haben. Das Projekt wurde mit v7.20.2 erstellt, da ich die
v7.20.1 gerade nicht installiert habe...
Vorgehensweise:
- ein frisches Projekt auf Basis des "main.c" Templates erstellt
- die Ziel-MCU auf den MSP430FR5949 geändert
- das *.xcl aus dem Installationsverzeichnis der Toolchain ins Projekt
kopiert
- in main.c ein paar sinnfreie Berechnungen mit Double und ein CONST
UINT32 Array eingefügt, um Speicherverbrauch >47kByte zu erzeugen
1
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
Guten Morgen Michael,
zunmächst vielen Dank für deine Untersützung. Ich habe mal das Linker
File von dir und meines verglichen. Es gibt da nur sehr wenig
unterscheide.
Nachfolgende Zeilen habe ich ja bereits getestet und funktioniert auch.
1
-P(CODE)CODE=4400-FF7F,10000-13FFF
2
-Z(CODE)CODE_PAD
Nun ist es so dass noch eine Checksummen Berechnung gemacht werden soll.
1
// Build a checksum of the code segment
2
-J2,sum=={CODE};
In der Checksum.c Datei wird ein pragama ausgeführt.
Ich vermute dass das damit zusammenhängt.
1
#pragma segment = "CODE"
2
3
u16u16startAddr[2];
4
u16startAddr[0]=(u16)__segment_begin("CODE");
5
6
u32u32endAddr[2];
7
u32endAddr[0]=(u16)__segment_end("CODE");
Fehlermeldung Linker:
Error[e171]: The segment "CODE" that is used in a checksum command is a
packed segment.
Hallo,
ich habe beim Beispiel aus dem ZIP mal in den General Options das Code
Model von "Large" auf "Small" umgestellt und dann meckert der Linker die
Bytes als "fehlend" an, die ansonsten ab 0x10000 liegen. Das könnte also
schon mal ein Grund dafür sein, dass in Deinem Projekt der obere
Speicherbereich nicht genutzt wird.
Was die Checksum angeht, so werde ich versuchen, mir das heute mal im
Detail anzuschauen, falls ich Zeit für finde. Zum Thema gibt es auch
eine Tech-Note, die Du Dir vorab mal anschauen kannst:
https://www.iar.com/knowledge/support/technical-notes/general/checksum-calculation-with-xlink/
Gruß,
Michael
Den Tech-Note habe ich gestern auch im Netz gefunden.
Da ich aufgrund von der -P Option sich um ein packed segment handelt
kann ich dann in meiner Checksummen Berechnung #pragma segment = "CODE"
nicht beutzen.
Zu der -P Option gibt es wohl kein Beispiel.
Entwickler schrieb:> Error[e171]: The segment "CODE" that is used in a checksum command is a> packed segment.
Zitat aus dem Linker Handbuch zu Fehler "E171":
Segment names used in a checksum command must be sequentially placed.
Place the segment using the option -Z or use an explicit address range
(like 0x200–0x37F) in the checksum command.
Wenn ich beim Beispielprojekt aus dem ZIP in den Linkeroptionen die
Prüfsummenberechnung aktiviere (und -Z(CODE)CHECKSUM=13FF6-13FF7 ins
*.xcl einfüge), dann führt das zu folgenden Parametern für den Aufruf
des Linkers und damit baut das Projekt:
-Hff -J2,crc16,,,,2,0
(rechts-klick in das Build-Message Fenster und dann den Filter auf "all"
umstellen, um den kompletten Aufruf der Tools zu sehen)
Ergebnis im *.map:
1
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
Kopieren des "-H" und "-J" in das *.xcl und abschalten der Optionen für
den Linker führt zum gleichen Ergebnis.
Laut den Adressen aus dem *.map würde die Prüfsumme den kompletten CODE
Bereich + den Reset-Vector umfassen, abzüglich des Platzhalters für die
Prüfsumme.
Nun zu checksum.c:
Das CODE Segment besteht aus 2 Teilen und somit hast Du 2x Start- und
Endadressen. Aktuell fällt mir außer der expliziten Angabe der Adressen
kein Weg ein, das sinnvoll im C-Code zu verarbeiten.
Gruß,
Michael
Moin,
wäre es ein gangbarer Weg, im *.xcl Symbole für die beiden unteren und
oberen Grenzen des FRAM zu definieren und damit zu arbeiten?
Also so in der Art:
Thread beobachten
Seitenaufteilung abschalten