• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1862 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

initialize DSP/BIOS bss & far sections to zero with autoinit.c

John Cumming
Prodigy 50 points

TI's "Uninitialized Static Objects Not Set to Zero in COFF" page, at

http://processors.wiki.ti.com/index.php/Uninitialized_Static_Objects_Not_Set_to_Zero_in_COFF ,

says,

Uninitialized static storage duration objects are not initialized to zero by the compiler when using COFF. The user must take extra steps to ensure these variables are initialized to zero.

The remedies there include using EABI, explicitly initializing variables in the source code, adding fill values to the linker command file & zeroing the .bss section before loading. The first 3 aren't sufficient choices right now, for various reasons.

Our DSP/BIOS application is loaded from the ARM with DSP/Link, so I suppose the loader is somewhere in DSP/Link.

I added a linker command file to define the start & end of .far, to make those address available when initializing:

SECTIONS {
        .far: {
            _far_start = .;
            *(.far)
            _far_end = .;
        } > DDR
}

One option: create a User Init Function and use it to zero the .bss section & .far section. It runs after the initialized variables in those sections are initted, but I can re-initialize them afterwards, using the cinit table. But the DSP/BIOS User Manual & API Manual aren't clear on when the User Init Fxn runs during startup, so BIOS_init() may set values in one of those sections before UserInitFxn runs. That makes this method questionable.

How do I modify the loader to init the .bss section and .far section?

What if I just modify the autoinit.c that came with my DSP/BIOS and add lines to zero those sections, then compile it as part of my project? That seems to work, and it's simple, but no one's suggested it. What's the downside?

This is for:

  • DSP/BIOS 5.41.13.42
  • OMAP L138 [TMS320C67XX]
  • TI v7.3.4 compiler
  • Output format: legacy COFF
  • Code Composer Studio v5.2.1

Thanks,

John

  • 0
    TI__Mastermind 37985 points
    John,
    UserInitFxn runs at the very beginning of BIOS_init(), so the order of execution will be the same if you either add your code as UserInitFxn or if you add it in _auto_init() right before calling BIOS_init().
    The downside of changing _auto_init() is that if you decide to upgrade to a different version of DSP/BIOS, you would have to go through the process of adding _auto_init() to your code. However, as DSP/BIOS is already deprecated there won't be too many new versions so that disadvantage doesn't seem that bad.
  • 0 in reply to Sasha Slijepcevic
    Prodigy 50 points
    Many thanks, Sasha! Now I know when the UserInitFxn runs.
    For upgrading to a newer version of the OS, it would be clearer to move the UserInitFxn across instead of bringing autoinit.c across. Though at that point, we should be using EABI, so the uninitialized variables will be 0.
  • 0 in reply to John Cumming
    Prodigy 50 points
    There is a benefit to clearing these sections at the beginning of _auto_init(), instead of the end. In that case, it's done before the startup sequence initializes .bss from the .cinit records.
    I still prefer the UserInitFxn over changing an OS file.
  • 0 in reply to John Cumming
    Prodigy 50 points

    For the record, initializing .bss from the UserInitFxn caused trouble with DSPLink. The DSP/BIOS application was loaded & started from the GPP via DSPLink, and PROC_start() returned an error, 0x80008052, indicating a config error mismatch. Creating an outbound message object in the GPP returned the same error code. The rest of DSPLink seems to work, but those problems make this approach questionable.