COFF -> EABI and DATA_SECTION

Matt Edmundson

Prodigy 95 points

Here is the basic information regarding my project:

CCS 5.1.0.09000

BIOS 6.32.05.54 (RTSC)

CGT 7.3.2

Target Processor : C674x (in the DM8168)

I have a fully functional DSP application that I'm migrating from COFF to EABI. The EABI project builds fine, but I have encountered a runtime problem where I require some guidance.

In my application, the Host processor and DSP use a shared memory structure to communicate with one another. The memory map looks like this (courtesy of my RTSC configuration):

SHMEM bc000000 01000000 006fcfb0 00903050 RW

VECS bd000000 00000200 00000200 00000000 RW X

DDR2 bd000200 02fffe00 012ba597 01d45869 RW X

So, the shared memory starts @ BC000000 and the CODE/DATA start @ BD000000.

In my BIOS configuration file, I defined:

Program.sectMap["SharedMemory"] = new Program.SectionSpec();
Program.sectMap["SharedMemory"].loadSegment = "SHMEM";

In my source, I defined:

#pragma DATA_SECTION("SharedMemory");
volatile audio_dsp_external_memory_t Host2DspSharedMemory;

In my design, the Host processor populates the shared memory structure with data that describes the DSP's role. The Host loads the DSP binary and manages DSP boot. The DSP application reads the shared memory structure at runtime to learn its role and then passes data back-and-forth to the Host via the shared memory structure.

This worked great for COFF, but is broken in my EABI version. It looks to me like the EABI binary load zeroes out the shared memory, which is not at all what I want. I confirmed this by using JTAG to first inspect the shared memory structure, then loaded the program, inspected shared memory again, and found its contents were initialized to zeroes.

From the COFF->EABI migration spec, I see:

"In ANSI C, global and static variables that are not explicitly initialized, must be set to 0 before program
execution. The C/C++ EABI compiler supports preinitialization of uninitialized variables by default. This
can be turned off by specifying the linker option --zero_init=off. COFF ABI does not support zero
initialization."

So, I rebuilt my application with '--zero_init=off'. Now, I see that the shared memory structure is no longer zeroed, but I have encountered other runtime problems that I don't yet understand.

Here's my question. Is my scheme for defining the shared memory structure as a DATA_SECTION the right way to create a shared memory structure? Is there a better way to map in this shared memory to the DSP application, where the EABI format will not result in a preinitialization of this memory?

Regards,

Matt

over 12 years ago

0 Matt Edmundson over 12 years ago

Prodigy 95 points

I suppose the easy answer is to treat shared memory like any other I/O memory, and address it directly, ala

volatile audio_dsp_external_memory_t *dsp_ext = (volatile audio_dsp_external_memory_t *)0xBC000000;

There is no compelling reason to treat shared memory as a DATA_SECTION, and thus subject to EABI preinitialization. It should be managed as any other I/O memory.

0 RandyP over 12 years ago in reply to Matt Edmundson

TI__Guru* 84110 points

Matt,

In the C6000 Assembly Language Tools v7.3 User's Guide, Section 7.3.33 talks about the autoinitialization, and that is probably where you found the --zero-init=off command. According to that section, ANSI C expects the zero fill of all uninitialized variables. Our COFF linker did not support this, but the EABI tools do.

In particular, this means that this was likely happening to all of your data space, including .bss, until you turned it off with --zero_init=off. Personally, I was not aware of this until now, and will try to make =off be the default in my linker builds from now on to avoid the extra cycles. Then again, I might toy with the idea to see if it is convenient enough to put up with it. As long as it is done by the C-init code and not by having a huge data block in the .out file, that will be fairly quick and painless.

Using the DATA_SECTION pragma to place your shared memory at a fixed location is precisely the way to setup a shared memory. There may be other ways to do this, but with the DATA_SECTION, you place your memory structure at a location that is defined in the linker command file and not by the "whims" of the linker when it tried to place various memory components among each other in a generic group like .bss or .far. With DATA_SECTION, you have the fixed location that can be assigned to the host code without as much worry about it moving. Of course, it can be best to routinely pass that address from the DSP to the Host for robustness, but the location will still be predictably at the same place each time for consistency.

Regards,
RandyP

Processors

Processors forum

COFF -> EABI and DATA_SECTION