• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 1065 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.

How to keep array from being zero_init'ed

John Conover
Genius 4350 points

Other Parts Discussed in Thread: AM3359

Hi,

      We have a piece of internal SRAM on the AM3359 being used as a reboot check and we have mapped it using the following define in the "c" file:

u32_t    boot_image[4] __attribute__((section (".bootvars")));

     The bootvars section is defined in the AM3359.cmd file as:

SECTIONS
{
#ifndef M3_CORE     /* A8 memory map */
    .bootvars: SRAM_END             /* End of internal SRAM for reboot logic */

     The problem we are having is that the linker is putting .bootvars in the .cinit area as you can see from the map file:

800868c8    00000008     (.cinit..bootvars.load) [load image, compression = zero_init]

     We don't want the memory cleared but left alone. Is there a linker command we can add to the .cmd file that will

keep the linker from zero initializing it?

Thanks,

     John C.

  • 0
    TI__Guru**** 253380 points

    I really don't like the solution I propose here.  I hope to think of something better.

    At a high level, do not define the array boot_image in C, but in the link command file.  Here is the syntax ...

       .bootvars 
          { . += 4 * 4; }  /* length = 4 words * 4 bytes/word */
          > RAM,
          RUN_START(boot_image)

    The first line names the section .bootvars.  The second line creates a 16-byte empty section.  The third line allocates the section to RAM.  Change RAM to whatever memory range you need.  The last line assigns the symbol boot_image to the start address of the section.  

    Back in C, you just need

    extern u32_t boot_image[];

    Hope this helps ...

    -George

  • 0 in reply to George Mock
    Genius 4350 points

    Hey George,

         Your suggestion works. I just can't believe that it is so difficult to have a variable located in a specific piece of memory that does not get zero init'ed. I had like the way I did it because from a maintainability standpoint you can trace down where the array will be located (in a .c or .h file). If you think of something better please let me know.

    Thanks a lot,

         John C.

  • 0 in reply to John Conover
    TI__Guru**** 253380 points

    Turns out there is a straightforward way to do it.  I'm a bit angry at myself for forgetting it.  You only need one change from the original.  Set the section type to NOINIT ...

    .bootvars: type = NOINIT, run = SRAM_END

    Note the NOINIT section type only has an effect when building for EABI.  EABI is the most common ABI in use with the ARM compiler today, but older ABI's are available.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4350 points

    Hey George,

         That was it! Thank you much for the help as it is exactly as it was originally with the .cmd file change.

    Thanks again,

         John C.

  • 0 in reply to George Mock
    Prodigy 40 points

    Just a small caveat to this solution. I have updated to version 5.04 of the ARM compiler today and it now appears that type=NOINIT is not working anymore.

    We're running external SRAm on the EPI and it causes a HW fault if you try to initialise it. The NOINIT was working on 5.01 and 5.03, but now if we compile with 5.04 you can see the __TI_cinit_table entry in the map file contains an entry for the external RAM despite the type=NOINIT.

    We've gone back to using 5.03 until it is fixed.

    Regards,

    Sean.

  • 0 in reply to Sean Stafford
    Genius 4350 points

    Hey Sean,

                 Thanks for the input. On Friday I gave my changes to a co-worker and he began having problems with the array being zero'ed out and mine was still fine. As it turns out he had 5.04 and I am using 5.03. So thanks again for saving us time as we had been looking into how it was possible with the same code base we had two different memory maps.

                  I wounder if TI has any temporary solutions as my co-worker had gone from 4.xx to 5.04.

    John C.

  • 0 in reply to John Conover
    Prodigy 40 points

    We found that you could just copy the arm_5.0.3 folder from c:\ti\ccsv5\tools\compiler to another machine and it would find it and allow you to use it.

    Regards,

    Sean.