• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 2613 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.

Workaround for "Zero Initialization of global variables" for COFF

Kevin Schuster
Expert 1210 points

Other Parts Discussed in Thread: SYSBIOS

Hello,

can anybody tell me how to do a workaround of zero init for COFF?

I am using DSP/BIOS 5.42 with CGT 7.4.8, and I cant use EABI because of no SYSBIOS support for DM6435.

I tried things like filling the .bss SECTION with 0, but this leads to some runtime errors. I also tried to write a function to set the .bss SECTION to 0 with memset, before auto_init gets called (Thread). Leads also to runtime errors. 

There is one solution missing, I was seeing in SPRU187U, Chapter 7.8.3 "Initialization Tables". 

Quote:

"The tables in the .cinit section consist of variable-size initialization records. Each variable that must be
autoinitialized has a record in the .cinit section. Figure 7-16 shows the format of the .cinit section and the
initialization records.

The fields of an initialization record contain the following information:
• The first field of an initialization record contains the size (in bytes) of the initialization data.
• The second field contains the starting address of the area within the .bss section where the
initialization data must be copied.
• The third field contains the data that is copied into the .bss section to initialize the variable.
Each variable that must be autoinitialized has an initialization record in the .cinit section.
Example 7-13 shows initialized global variables defined in C. Example 7-14 shows the corresponding
initialization table. The section .cinit:c is a subsection in the .cinit section that contains all scalar data. The
subsection is handled as one record during initialization, which minimizes the overall size of the .cinit
section."

Is it possible somehow to get the records of .cinit to set the .bss init data to 0? If yes, how? Or is there any other workaround to set global variables to 0?

  • 0
    TI__Guru**** 253380 points

    Kevin Schuster said:
    I tried things like filling the .bss SECTION with 0, but this leads to some runtime errors. I also tried to write a function to set the .bss SECTION to 0 with memset, before auto_init gets called (Thread). Leads also to runtime errors. 

    Those are the two main solutions.  I don't know why you would see any problems.  How much did you investigate these runtime errors?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 1210 points

    Hi George,

    I am debugging the first solution right now. I tried to put this line in my cmd-file:

    .bss:        fill = 0x00


    There are 2 possibilities depending on the Link Order to build the project. Either my own cmd-file gets called before the "Generated Linker Command files" or the other way round.

    Generated before own cmd file:

    out-file was built and loaded without any problems, program is working fine, system is running without problems. BUT, the global variables are not initialized with 0. I tried to check a non initialized global variable during runtime. I set a breakpoint to check the value and first it was zero. I reset the value while I was staying at the breakpoint and reloaded the out-file. After starting the program again, the value didnt change back to zero as I expected. It had the value I was setting. So this Link Order didnt help.

    Own cmd file before Generated file:

    out-file was built with a warning:

    "warning #10423-D: No placement specified for ".bss"; a default placement will be applied.

    Loading out-file was working fine, setting the break point and resetting the value of the global variable worked (variable is 0 after reloading the out-file), but running the program led to an "Instruction fetch exception".

    Do you have any idea how to handle that Instruction fetch exception?

  • 0 in reply to Kevin Schuster
    Expert 1210 points

    I guess I found the answer by myself. The solution was to find out what causes the build warning. I forgot to write where to put the .bss Section, so this line resolved the warning:

    .bss:     fill = 0x00 > DDR2

    The warning is gone and also the Exception. Program is running fine now, and the global variable is zero after every new reload!