Tasking VX, why is the predefined data file linked twice

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
WaltSnowrancruz
Level 1
Level 1
5 sign-ins First question asked Welcome!

Cannot figure out, why is my file (containing only DataFlash0 byte defines) linked into the output hex twice. I am compiling for Infineon TC1797 with Tasking VX compiler.

Besides the program, I have a file named data_flash_bank_0.asm, which only includes predefined data bytes.

Compiler properly places it at the expected address of 0x8FE00000, which is the data flash 0 in hardware.

What is wrong is that the same code appears within the program as a second copy, wasting space and not wanted.

All the setting in the project properties seems fine, 'delete duplicate' enabled.

To illustrate the problem, I made one VERY SMALL project, where there are only 3 files: test.c function with main(), short assembly function reading the data flash, and the data flash predefines.

test.c:

 #include <stdio.h>

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

 int main(void)
 {
    loop_36();
 }

assembly function 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

and the actual predefined bytes area giving me the problem, file data_flash_bank_0.asm:

 .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: (the last line is what I expect, but the 2 lines above it, also length 0x8000, I do not want)

 +------------------------------------------------------------------------------------------------------------------------+
 | 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 |
0 Likes
1 Solution
User13836
Level 6
Level 6
50 likes received 50 solutions authored 100 sign-ins

Hello Walt,

please add the rom keyword to the data definition. I suggest to follow the Infineon EABI spec which requires to use the section name prefix .rodata for constant, far accessed data:

 .sdecl ".rodata.dflash0", DATA, ROM AT 0x8FE00000
 .sect ".rodata.dflash0" ; 

 If ROM is omitted, the linker will treat the data as initialized data and create a ROM copy for the initialization when the linker generated copy table is processed during the C startup code execution.

 

Best regards,

Ulrich Kloidt
TASKING Tools support

View solution in original post

0 Likes
2 Replies
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi walt,

I have used Bifaces and Tasking to add your asm code into Dflash0, and below is a 2 byte example.

dw_0-1652266602780.png

dw_1-1652266688511.png

dw

0 Likes
User13836
Level 6
Level 6
50 likes received 50 solutions authored 100 sign-ins

Hello Walt,

please add the rom keyword to the data definition. I suggest to follow the Infineon EABI spec which requires to use the section name prefix .rodata for constant, far accessed data:

 .sdecl ".rodata.dflash0", DATA, ROM AT 0x8FE00000
 .sect ".rodata.dflash0" ; 

 If ROM is omitted, the linker will treat the data as initialized data and create a ROM copy for the initialization when the linker generated copy table is processed during the C startup code execution.

 

Best regards,

Ulrich Kloidt
TASKING Tools support

0 Likes