COFF File target download from host

Shiras Pallikkara

Other Parts Discussed in Thread: STRIKE

Hi,

I have a DSP Project based on C6415 target.I am using the CCS Ver 3.1.0 and CGT Ver 5.1.0. I have 2 COFF output files generated by building my project on this environment- One with BIOS Ver.4.90 and other with BIOS ver.5.20.05. Both COFF files runs on my target when loaded through emulator.My requirement is to load the COFF file from a windows application running on the host.The DSP target is interfaced to the host via PCI Interface. The COFF file built using BIOS Ver.4.90 when loaded by host, runs fine on the DSP target and give the desired results.But the COFF file built using BIOS Ver.5.20.05 when loaded by host, doesn't run on the DSP target.
I have compared the section details of the 2 COFF files from the log messages which i got from my COFF file parser function in my windows application. The differences i found are as follows:

1- In COFF built with BIOS Ver.5.20.05,.stack section has section header flag as 0x380(means Section contains uninitialized data and so not written to target memory), but in the COFF built with BIOS Ver.4.90,.stack has section header flag as 0x340(means Section contains initialized data and so written to target memory).

From the auto generated command file of project built with BIOS Ver.4.90
.stack: fill=0xc0ffee {

GBL_stackbeg = .;

*(.stack)

GBL_stackend = GBL_stackbeg + 0x800 - 1;

_HWI_STKBOTTOM = GBL_stackbeg + 0x800 - 4 & ~7;

_HWI_STKTOP = GBL_stackbeg;

} > ISRAM

From the auto generated command file of project built with BIOS Ver.5.20.05
.stack: {

GBL_stackbeg = .;

*(.stack)

GBL_stackend = GBL_stackbeg + 0x800 - 1;

_HWI_STKBOTTOM = GBL_stackbeg + 0x800 - 4 & ~7;

_HWI_STKTOP = GBL_stackbeg;

} > ISRAM

The fill parameter is missing in the 5.20.05 command file

2-In BIOS Ver.5.20.05 COFF file,.printf section has header flag as 0x40 which indicates Section contains initialized data and so it is written to target memory.But in BIOS Ver.4.90 COFF file,.printf section has header flag as 0x4010 which indicates Section requires conditional linking and is a Copy section (relocated, loaded, but not allocated; relocation entries are processed normally)and so it is not written to target memory.

In BIOS Ver.4.90 autogenerated cmd file, i see the following line.
.printf (COPY): {} > ISRAM
But i dont see an entry for .printf in the BIOS Ver 5.20.05 autogenerated cmd file.

3-LOG_system and ScLog are LOG objects under Instrumentation->LOG-Event Log Manager in the BIOS Configuration file.
In BIOS 4.90 autogenerated cmd file, the following entry is found.

/* LOG_system buffer */

.LOG_system$buf: align = 0x100 fill = 0xffffffff {} > ISRAM

/* ScLog buffer */

.ScLog$buf: align = 0x100 fill = 0xffffffff {} > ISRAM

In BIOS 5.20 autogenerated cmd file, the following entry is found.

/* LOG_system buffer */

.LOG_system$buf: align = 0x100 {} > ISRAM

/* ScLog buffer */

.ScLog$buf: align = 0x100 {} > ISRAM

The fill parameter is missing in BIOS 5.20 cmd file.

In the 5.20 COFF file, the section header flags for the above two sections are 0x280 which indicates that Section contains uninitialized data and so its not written to target memory. In the 4.90 COFF file, the section header flags for the above two sections are 0x240 which indicates that Section contains initialized data and so its written to target memory.

4- Since 5.20 BIOS does not support CSL Configuration under the DSP/BIOS configuration in the tcf file, i am told to call cslCfgInit() in my main function.
I am finding the below entry in my BIOS 5.20 project Map file

.text:cslCfgInit
* 0 000dbaa0 00000200
000dbaa0 00000200 rficfg_csl.obj (.text:cslCfgInit)

This section has section header flag as 0x520 which corressponds to Section contains executable code and so is written to target memory.

These are the 4 differences i am finding, in between the BIOS 4.90 COFF file(working) and BIOS 5.20.05 COFF file(non-working).I am emphasizing the fact that both these COFF files used the same build environment except the BIOS versions and both are working when loaded through emulator.But COFF from BIOS Ver.5.20.05 doesnt work when loaded from the host application. Please let me know if something could go wrong by having the above differences, which could cause the COFF from BIOS 5.20.05 from not running when loaded from host application.

over 16 years ago

0 Karl Wechsler over 16 years ago

TI__Mastermind 20805 points

Most of the above differences don't strike me as a problem. In BIOS 5.x, we do those "fill" initializations are boot time to minimize the COFF file/download size and to also also make FLASH size smaller. Those sections can be very large and we had to allocate big chunks of memory to hold those initialization values.

The .printf section is curious though. Can you look at your .map file and see if you have any data in your .printf section and also check where that data is loaded? If the linker does not see the a section spec, it will place the code at some default location which could be a problem. You can add a second linker .cmd file to your project to place .print (like was done in your 4.90 app). .printf section is usually empty. It holds strings for the assembly macro version of LOG_printf which is seldom used.

Can you check to see if you are using the same linker option for C initialization (-c or -cr)? One of these does "boot time initialization" where the target processes the cinit records, while the other is "load time" where loader does the cinit processing. The -c or -cr options might be hidden in the BIOS-generated .cmd file.

One approach to debug this would be to add an infinite loop at main() and load your program with your host loader. You can then attache with CCS and halt the target. The use the CCS "save memory" option to save memory to a file. You could do same with the CCS loaded version and compare the files to see what's different.

0 Shiras Pallikkara over 16 years ago in reply to Karl Wechsler

Intellectual 445 points

In the 4.90 autogenerated .cmd file, i see the following entry

.printf (COPY): {} > ISRAM

So since the .printf is a COPY section, in 4.90 map file, I dont find an entry for .printf section. In 4.90 COFF file, for the .printf section, the section start address is 0x0 and size is 0x0 and section header flag is 0x4010 which corressponds to Copy section (relocated, loaded, but not allocated; relocation entries are processed normally) and Section requires conditional linking.

In 5.20 autogenerated .cmd file, I dont have an entry for .printf. But in the corressponding map file, i have the below entry for .printf.

.printf 0 000dfd40 0000005c

000dfd40 0000005c rficfg.obj (.printf)

(rfi is my project name).

In the 5.20 COFF file,for the .printf section, the section start address is 0xdfd40(some address in the ISRAM, but its not 0x0 as is in the 4.90 COFF file), size 0x5c( not 0x0 as in the 4.90 COFF file), flags 0x40( indicates Section contains initialized data and is not a COPY section as is in the 4.90 COFF file). One more difference is that the .printf section in 5.20 is written to target memory by my host loader as it finds the flag as 0x40. But the host loader doesnt write this section in 4.90 to the target memory as the flag indicates that it is a COPY section.

So this means that 5.20 .printf section contains some data and is loaded to address 0xdfd40 while the 4.90 .printf section doesnt contain any data as the size is 0 and the load address is 0.

As per you suggession,I tried adding .printf section definition to my custom linker command file in 5.20 project as seen in 4.90 autogenerated .cmd file.

.printf (COPY): {} > ISRAM

The generated map file now doesnt have any .printf section entry and the COFF file section header flag for .printf section became 0x50 which indicates that it is a Copy section (relocated, loaded, but not allocated; relocation entries are processed normally) and Section contains initialized data. The section start address now became 0x0 (same as 4.90 COFF) and size is still 0x5c(in 4.90, it is 0x0).Since the section header flag indicates that it contains some initialised data(eventhough it is a COPY section), it is written to address 0x0 of the target memory(but it s not written in the case of 4.90 COFF). If this can be a potential cause of the problem that i am getting, the questions that i have unanswered are:

1- Eventhough i define .printf section in the same way in both BIOS version projects,why am i getting a different section header flag and size for .printf section?
2- Do you think if the section header flag and size for .printf are made the same, it would solve the problem of COFF file not running when downloaded from the host?
3- If the problem is due to .printf section, why the same COFF file works when loaded through Emulator and doesnt work when loaded from the host application?

Regarding the Autoinit Model under the linker tab in the build options, both the projects have Runtime-Autoinitialisation (-c) enabled.I didnt find these options in the autogenerated .cmd file, as you said. Instead i checked it in the Build options for both the projects.

Please let me know if any of the findings above stroke you as a problem. I will update again based on my findings, after doing the "Save Memory" option in CCS to debug the problem, as per your suggession in your previous post.

0 Ramana_Munich over 16 years ago in reply to Shiras Pallikkara

Expert 1660 points

Hi,

I am also facing the same problem, but i found some interesting things. As i am

using the DSPC6452 and the bios version 5.31.02, i am getting the problem that

i can load the .out file from the target and works fine but when i tried to load it from the host over PCIe it does not work. As i debugged from the host side, i found that the .gblinit section is overlapped by the .printf section

while .printf is a copy section. Interestingly in my .cmd file i see the .printf section but i can't see in my .map file, i dont know why! So when i started my DSP debugging with this setup, it exactly breaks at the GBL_init. so i checked the flag value in the host,when the printf section comes it is 0x50(0x10copy section(relocated, loaded,but not allocated ) + 0x40(section contains initialized data)). so this contains the copy section, so i skipped this section to write to the target memory. then my .out file from the host works properly, but what i don't understand is when the flag is 0x50,it contains also initialized data with the copy section, principally i skipped this to write to the target memory, but i am not happy that i am also skipping th initialized data in it.Do you have any idea about this?

Secondly i have one question, in the spec it specifies the bits 8 to 11 are for the alignment, and after taking pow(2, bits(8-11)), you get the alignment.so, as i understand that í have to add this alignment(assumed in bytes) to the physical address of the DSP ? is it right what i understood?

i hope this helps,

Thanks,

0 Ramana_Munich over 16 years ago in reply to Ramana_Munich

Expert 1660 points

By the way i am giving the .printf section defined in my .cmd file.

GROUP {

.const: align = 0x8 {}

.printf (COPY): {}

} > IRAM

Processors

Processors forum

COFF File target download from host