This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCSV4 - .bss zero fill

Other Parts Discussed in Thread: TMS320VC5502

I am using CCSV4 Version 4.2.4.00033, which came with a TMS320C5502 eZDSP development kit. I'm trying to get hex55 to "zero fill" the .bss section, which, according to document SPRU281g can be accomplished by adding the following line to link.cmd:

SECTIONS

{

...

.bss: {} = 0x00;

...

}

Accordingly, I modified the file like so:

SECTIONS
{
   .text     > RAM    PAGE 0  /* Code                       */

   /* These sections must be on same physical memory page   */
   /* when small memory model is used                       */
   .data     > RAM    PAGE 0  /* Initialized vars           */
   .bss      > RAM    PAGE 0  /* Global & static vars       */
   .bss: {} = 0x00;
   .const    > RAM    PAGE 0  /* Constant data              */
   .sysmem   > RAM    PAGE 0  /* Dynamic memory (malloc)    */
   .stack    > RAM    PAGE 0  /* Primary system stack       */
   .sysstack > RAM    PAGE 0  /* Secondary system stack     */
   .cio      > RAM    PAGE 0  /* C I/O buffers              */

   /* These sections may be on any physical memory page     */
   /* when small memory model is used                       */
   .switch   > RAM    PAGE 0  /* Switch statement tables    */
   .cinit    > RAM    PAGE 0  /* Auto-initialization tables */
   .pinit    > RAM    PAGE 0  /* Initialization fn tables   */

    vectors  > VECS   PAGE 0  /* Interrupt vectors          */

   .ioport   > IOPORT PAGE 2  /* Global & static IO vars    */
}

And I get the following error message:


"../lnk.cmd", line 59: error: expecting output section, GROUP, or UNION instead
   of "="
error: errors encountered during linking; "ProLinkIIPlus.out" not built

Can you tell me the proper format, please?

For background, this is a project using a TMS320VC5502 which was originally compiled 4 years ago on a pre Eclipse version of the compiler. The program is contained on a serial EEPROM that connects to the DSP over the I2C bus. Everything worked fine. I'm am in the process of modifying the code, but CCSV4 and whatever version of hex55 I was using are very different from CCSV4 and hex55 version 4.3.8.

Thanks.

Mike

  • Change the .bss line to ...

    .bss      > RAM    PAGE 0, fill = 0

    The downside to this approach is your hex files becomes larger by the size of .bss.  If that becomes a problem, then you should consider modifying the boot routine _c_int00 to zero fill .bss.

    Thanks and regards,

    -George

  • Thanks, George. How would I modify _c_int00?
  • Well, the good news is that the .bss zero fill worked. I have moved all of the non-zero initialized variables to the .const section and all zero filled variables to the .bss section, and that's working. However, the program will still not start after loading from the EEPROM. Using CCSV4, I can verify that the .txt, .bss, and .const sections are correctly loaded into the VC5502's RAM after power up.

    Any ideas as to why the program won't start (it never reaches main)? The program executes just fine after loading via CCSV4 and the XDS100V2 JTAG Emulator.

    Another question. After starting CCSV4, if I launch the TI debugger and connect to the target and subsequently read memory, I am seeing what was loaded into RAM from the EEPROM, correct? Is there a way to re-start the DSP at a specified point (e.g., the entry point of .boot)? I would like to single step through the code from that point.

    Thanks again.

    Mike
  • I lack the expertise to help you with these system startup issues.  I suggest you start a new thread in the C5000 device forum. Or, if you prefer, I can move this thread into that forum.

    Thanks and regards,

    -George

  • I presume you only moved const variables to the .const section?
  • Yes. The initial problem (a few days ago) was that hex55 was placing initialized variables in the .bss section, and therefore, they were not initialized. For example:

    int abc[] = {123, 456, 789};

    'abc" was placed in the .bss section by default.

    I changed it to:

    const int  abc[] = {123, 456, 789};

    which placed "abc" in the .const section.

    I left non initialized variables such as "int xyz;" alone, placing them in .bss, which now "zero fills" them.

    Thinking about it, a remaining problem are initialized variables for which the CONST declaration is inappropriate, such as "unsigned int ti = 987", where the contents will be changed within the code. I will have to explicitly initialize them (i.e., ti =87;) in the code.

    My more immediate problem is how to force the program counter to a location in boot.obj, for which source code does not exist (it's part of the rts55x library). I'd like to single step the code starting at that location. Any ideas?

    Thanks.

    Mike

  • Non-const initialized variables are supposed to be initialized at startup time by the autoinit routine called by _c_int00.  If they weren't being initialized, there's a bug somewhere.

    I'm not sure under what conditions you want to set the PC.

    If in CCS, just edit the PC register display with the address you want; CCS should take care of writing to the actual register.

    If in assembly code, add a direct branch to that address.

    In the linker, you could set the entry point to that address.

  • "If they weren't being initialized, there's a bug somewhere."

    Hmm, I sort of figured that ..

    From what I understand, the TMS320C55xx bootloader is supposed to jump to a routine called "boot", and the bootloader table does specify that address. I'll try stepping through that routine - that's why I wanted to know how to force the PC counter to a specific address.

    Mike
  • Thanks for the tip. I found the register display option under the view tab.

  • Sorry, my fingers did not type what I was thinking...
    The .bss variables aren't expected to be initialized until after autoinit has finished. If they aren't initialized after autoinit, there's a bug.
  • Got it! They are not, in fact, being initialized. From what I can tell, _c_int00 is never entered, although its address is clearly listed as the "jump to" address for the bootloader in the .map file. At this point, I suspect that my EEPROM has a problem, because the EEPROM programmer is giving me inconsistent data when I read the EEPROM contents. The first 4 bytes should be the "starting address" (0x89DE in my case), but the EEPROM reads 0x76DE.

    The remark was never intended to be "snarky", but in retrospect, I can see how it could be interrupted that way.

    Mike