Tasking VX, warum ist die vordefinierte Datendatei doppelt verknüpft?

Question

Kann nicht herausfinden, warum meine Datei (die nur das Byte DataFlash0 definiert) zweimal in das Ausgabe-Hexadezimalfeld eingebunden wird. Ich kompiliere für Infineon TC1797 mit Tasking VX Compiler.

Neben dem Programm habe ich eine Datei mit dem Namen data_flash_bank_0.asm, die nur vordefinierte Datenbytes enthält.

Compiler legt sie richtig auf die erwartete Adresse des 0x8FE00000, die die Daten-Flash 0 in Hardware.

Was falsch ist, ist, dass der gleiche Code innerhalb des Programms als eine zweite Kopie erscheint, Platz verschwenden und nicht wollte.

Alle Einstellungen in den Projekteigenschaften scheint in Ordnung zu sein, 'delete duplicate' aktiviert.

Um das Problem zu veranschaulichen, habe ich ein sehr kleines Projekt, wo gibt es nur 3 Dateien: test.c Funktion mit main(), kurze Assembly-Funktion Lesen der Daten-Flash, und der Daten-Flash vordefiniert.

test.c:

#include <stdio.h> 

extern void * loop_36(void); // call the main assembly function 

int main(void) 
{ 
    loop_36(); 
} 

Montagefunktion jozo.asm:

.sdecl "PFLASH", CODE 
.sect "PFLASH" 

.global loop_36 

loop_36: 
    movh.a  a4, #0x8FE0 
    mov16  d2, #0  ; Move 
    lea  a2, 0x3F ; Load Effective Address 

loop: 
    ld16.w  d15, [a4+]4 ; Load Word 
    or.ne  d2, d15, #0 ; Not Equal Accumulating 
    loop16  a2, loop ; Loop 
    ret16     ; Return from Call 

.end 

und die tatsächliche vordefinierte Bytes Bereich mir das Problem, Datei data_flash_bank_0.asm geben:

.sdecl ".data.dflash0", DATA AT 0x8FE00000 
.sect ".data.dflash0" ; new edit: trying .rodata instead of .data 

.byte 0xF2, 0x45, .... 32k more bytes 

.end 

Map file: (die letzte Zeile ist, was ich erwarte, aber die 2 Zeilen darüber, als o Länge 0x8000, ich will nicht)

+------------------------------------------------------------------------------------------------------------------------+ 
| Chip  | Group | Section         | Size (MAU) | Space addr | Chip addr | Alignment | 
|  ========================================================================================================================| 
| spe:pflash0 |   | .text._Exit.libc (191)     | 0x00000004 | 0x80000008 | 0x00000008 | 0x00000008 | 
| spe:pflash0 |   | .text._c_init.libcs_fpu (98)    | 0x0000000c | 0x8000000c | 0x0000000c | 0x00000002 | 
| spe:pflash0 |   | .text._c_init_entry.libcs_fpu (97)  | 0x00000132 | 0x80000020 | 0x00000020 | 0x00000020 | 
| spe:pflash0 |   | table (202)        | 0x00000030 | 0x80000154 | 0x00000154 | 0x00000004 | 
| spe:pflash0 |   | .text._ldmst_clear_byte.libcs_fpu (95) | 0x0000002e | 0x80000184 | 0x00000184 | 0x00000002 | 
| spe:pflash0 |   | .text._ldmst_copy_byte.libcs_fpu (96)  | 0x00000044 | 0x800001b2 | 0x000001b2 | 0x00000002 | 
| spe:pflash0 |   | .text.cstart..cocofun_1 (14)    | 0x0000001a | 0x800001f6 | 0x000001f6 | 0x00000002 | 
| spe:pflash0 |   | .text.cstart.__init_sp (12)    | 0x0000001c | 0x80000210 | 0x00000210 | 0x00000002 | 
| spe:pflash0 |   | .text.cstart._start (13)     | 0x000001c2 | 0x8000022c | 0x0000022c | 0x00000002 | 
| spe:pflash0 |   | .text.sync_on_halt._sync_on_halt (61)  | 0x0000008e | 0x800003ee | 0x000003ee | 0x00000002 | 
| spe:pflash0 |   | .text.sync_on_halt._sync_on_halt_end (60) | 0x0000000c | 0x8000047c | 0x0000047c | 0x00000002 | 
| spe:pflash0 |   | .text.test.main (84)      | 0x0000000c | 0x80000488 | 0x00000488 | 0x00000002 | 
| spe:pflash0 |   | [.data.dflash0] (203)      | 0x00008000 | 0x80000494 | 0x00000494 | 0x00000001 | 
| spe:pflash0 |   | PFLASH (5)        | 0x00000014 | 0x80008494 | 0x00008494 | 0x00000001 | 
| spe:dflash0 |   | .data.dflash0 (1)       | 0x00008000 | 0x8fe00000 | 0x0  | 0x00000001 | 

Answer 1

Der Tasking VX-Linker leitet die Segmenttyp und andere Metadaten basiert auf dem Namen eines Abschnitts. Die .data in .data.dflash0 bedeutet initialisiert Daten. Das ist ein Lese-Schreib-RAM-Speicher, für den während des Starts ein Anfangszustand aus dem ROM kopiert wird. Die zweite Kopie in PFLASH, die Sie sehen, ist diese Initialisierungskopie.

Die Lösung ist es, den Abschnitt .rodata prefix stattdessen zu verwenden, die für die Nur-Lese-Daten vorgesehen ist.

Effektiv der Linker wurde eine absolute Adresse gegeben und gesagt, dass es initialisieren und muß so davon ausgehen, dass es durch RAM unterstützt wird. Abgesehen davon, dass Speicherplatz verschwendet wird, ist es natürlich auch eine schlechte Idee, dass der CRT-Startversuch versucht, in FLASH zu schreiben.

Übrigens sind die .data und .rodata keine magisch hartcodierten Namen. Ein Linker-Skript, in diesem Fall das Standard-Skript, enthält Gruppendirektiven, die angeben, in welchem ​​Speicherbereich sich jeder der einzelnen Abschnitte befinden soll, sowie Attribute wie nocopy, um die Initialisierung zu steuern.