• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 951 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.

hanging in autoinit

David Lill
Prodigy 60 points

Other Parts Discussed in Thread: SYSBIOS

Hi,

I'm seeing a strange issue that involves auto_init() going into the weeds when the .cinit section is not 4byte aligned.  I searched the forums on this and found that I needed to ensure that I'm using the right version of code gen tools.  Well, I just updated to 7.3.0, which is the latest on the site, and I still have the same issue. 

After some further debugging, I noticed that the issue would happen when I was initializing an unsigned short static variable in a function in my ethernet.c file.  This resulted in a 10 byte long cinit record for ethernet.obj (4 byte length + 4 byte address + 2 bytes of data).  See below:

.cinit     0    0082c2e0    000018c2    
                  0082c2e0    00001314     certapp_dsp.p64Pe.obj (.cinit)
                  0082d5f4    00000004     --HOLE-- [fill = 0]
                  0082d5f8    00000254     hii.obj (.cinit)
                  0082d84c    00000004     --HOLE-- [fill = 0]
                  0082d850    00000104     ipc.obj (.cinit)
                  0082d954    00000004     --HOLE-- [fill = 0]
                  0082d958    0000005c     rts64pluse.lib : defs.obj (.cinit)
                  0082d9b4    00000004     --HOLE-- [fill = 0]
                  0082d9b8    0000005c                    : lowlev.obj (.cinit)
                  0082da14    00000004     --HOLE-- [fill = 0]
                  0082da18    00000048                    : cos.obj (.cinit)
                  0082da60    00000048                    : sin.obj (.cinit)
                  0082daa8    0000003c     periphTest.obj (.cinit)
                  0082dae4    00000004     --HOLE-- [fill = 0]
                  0082dae8    0000002c     rts64pluse.lib : exit.obj (.cinit)
                  0082db14    00000004     --HOLE-- [fill = 0]
                  0082db18    0000001c     main.obj (.cinit)
                  0082db34    00000004     --HOLE-- [fill = 0]
                  0082db38    0000001c     rts64pluse.lib : _lock.obj (.cinit)
                  0082db54    00000004     --HOLE-- [fill = 0]
                  0082db58    0000001c                    : atexit.obj (.cinit)
                  0082db74    00000004     --HOLE-- [fill = 0]
                  0082db78    0000000c                    : fopen.obj (.cinit)
                  0082db84    00000004     --HOLE-- [fill = 0]
                  0082db88    0000000c                    : sinit.obj (.cinit)
                  0082db94    00000004     --HOLE-- [fill = 0]
                  0082db98    0000000a     ethernet.obj (.cinit)

.stack     0    0082dba8    00001000     UNINITIALIZED
                  0082dba8    00000008     certapp_dsp.p64Pe.obj (.stack)
                  0082dbb0    00000ff8     --HOLE--

If I were to change the variable type to an unsigned int, then the cinit record changes to 12 bytes long and the issue goes away.  See below:

.cinit     0    0082c2e0    000018c4    
                  0082c2e0    00001314     certapp_dsp.p64Pe.obj (.cinit)
                  0082d5f4    00000004     --HOLE-- [fill = 0]
                  0082d5f8    00000254     hii.obj (.cinit)
                  0082d84c    00000004     --HOLE-- [fill = 0]
                  0082d850    00000104     ipc.obj (.cinit)
                  0082d954    00000004     --HOLE-- [fill = 0]
                  0082d958    0000005c     rts64pluse.lib : defs.obj (.cinit)
                  0082d9b4    00000004     --HOLE-- [fill = 0]
                  0082d9b8    0000005c                    : lowlev.obj (.cinit)
                  0082da14    00000004     --HOLE-- [fill = 0]
                  0082da18    00000048                    : cos.obj (.cinit)
                  0082da60    00000048                    : sin.obj (.cinit)
                  0082daa8    0000003c     periphTest.obj (.cinit)
                  0082dae4    00000004     --HOLE-- [fill = 0]
                  0082dae8    0000002c     rts64pluse.lib : exit.obj (.cinit)
                  0082db14    00000004     --HOLE-- [fill = 0]
                  0082db18    0000001c     main.obj (.cinit)
                  0082db34    00000004     --HOLE-- [fill = 0]
                  0082db38    0000001c     rts64pluse.lib : _lock.obj (.cinit)
                  0082db54    00000004     --HOLE-- [fill = 0]
                  0082db58    0000001c                    : atexit.obj (.cinit)
                  0082db74    00000004     --HOLE-- [fill = 0]
                  0082db78    0000000c     ethernet.obj (.cinit)
                  0082db84    00000004     --HOLE-- [fill = 0]
                  0082db88    0000000c     rts64pluse.lib : fopen.obj (.cinit)
                  0082db94    00000004     --HOLE-- [fill = 0]
                  0082db98    0000000c                    : sinit.obj (.cinit)

.stack     0    0082dba8    00001000     UNINITIALIZED
                  0082dba8    00000008     certapp_dsp.p64Pe.obj (.stack)
                  0082dbb0    00000ff8     --HOLE--

Why is this and what can I do to fix it? 

(please don't tell me to only pre-init statics that are unsigned int)  :)

I should mention that I am building from the command line using a custom makefile (no CCS involved in building).  I'm using SysBIOS as well. 

XDCTOOLS: 3.20.08.88

C6000_CGT: 7.3.0

IPC: 1.21.02.23

 

Thanks,

Dave

  • 0
    TI__Expert 8055 points

    David,

    I'm going to move this thread to the Compiler Forum.  There shouldn't be any reason that you can't pre-initialize a static 8-bit value.  I think the Compiler/Linker should handle all of this for you. 

     

    Regards,
    Dan

     

  • 0
    TI__Guru* 84285 points

    The map file snippet you show does not show a problem.  auto_init is capable of handling a cinit record of an odd size.  What matters is that each record must be aligned to 8 bytes, not 4.  (If the requirement were 4 bytes, you would not see those holes of exactly 4 bytes.)  All of the records in your before and after cases are 8-byte aligned, so I don't see a problem.  I would probably need to see the whole executable to debug this problem.

  • 0 in reply to Archaeologist
    Prodigy 60 points

    Thanks,

    I think found the issue.  I was missing the --rom_model switch during linking.  This puts in 4 bytes of  zero pad (after putting in a final 8 byte align hole) at the end of the cinit section.  The auto_init() routine uses this to know when to terminate parsing of the cinit records (determined from stepping through it).  Without the zero pad, auto_init() would see some garbage value in uninitialized memory and treat that as a memcpy 'size' and all hell would break loose.  I was able to get around it for a while by zero-filling the memory space (in my case the IRAM) so at least the memory section after cinit started with a Zero.  I'm not sure if this is part of a larger issue or not.  I mean, maybe auto_init() is not supposed to be used without the  --rom_model (and --ram_model according to the docs) linker switches present?  If that's the case, it would be nice if this info was commented in the auto_init() source since I would never have thought to dig 143 pages into SPRU514D were it not for some other forum discussion about the cinit section (different issue).  Regardless, FWIW on my findings.  It's working now!

    Here's what my cinit section looks like with that --rom_model switch:

    .cinit     0    0082c988    00001804    
                      0082c988    00001314     certapp_dsp.p64Pe.obj (.cinit)
                      0082dc9c    00000004     --HOLE-- [fill = 0]
                      0082dca0    00000254     hii.obj (.cinit)
                      0082def4    00000004     --HOLE-- [fill = 0]
                      0082def8    0000005c     ipc.obj (.cinit)
                      0082df54    00000004     --HOLE-- [fill = 0]
                      0082df58    0000005c     rts64pluse.lib : defs.obj (.cinit)
                      0082dfb4    00000004     --HOLE-- [fill = 0]
                      0082dfb8    0000005c                    : lowlev.obj (.cinit)
                      0082e014    00000004     --HOLE-- [fill = 0]
                      0082e018    00000048                    : cos.obj (.cinit)
                      0082e060    00000048                    : sin.obj (.cinit)
                      0082e0a8    0000003c     periphTest.obj (.cinit)
                      0082e0e4    00000004     --HOLE-- [fill = 0]
                      0082e0e8    0000002c     rts64pluse.lib : exit.obj (.cinit)
                      0082e114    00000004     --HOLE-- [fill = 0]
                      0082e118    0000001c                    : _lock.obj (.cinit)
                      0082e134    00000004     --HOLE-- [fill = 0]
                      0082e138    0000001c                    : atexit.obj (.cinit)
                      0082e154    00000004     --HOLE-- [fill = 0]
                      0082e158    0000000c     ethernet.obj (.cinit)
                      0082e164    00000004     --HOLE-- [fill = 0]
                      0082e168    0000000c     rts64pluse.lib : fopen.obj (.cinit)
                      0082e174    00000004     --HOLE-- [fill = 0]
                      0082e178    0000000c                    : sinit.obj (.cinit)
                      0082e184    00000004     --HOLE-- [fill = 0]
                      0082e188    00000004     (.pad.cinit) [fill = 0]

    .stack     0    0082e190    00001000     UNINITIALIZED
                      0082e190    00000008     certapp_dsp.p64Pe.obj (.stack)
                      0082e198    00000ff8     --HOLE--

    Regards,

    Dave

  • 0 in reply to David Lill
    TI__Guru**** 253170 points

    It seems you were linking C code while not using either the --rom_model or --ram_model switch.  As you've seen, such a combination doesn't work.  Please tell me how that came to happen.  We might be able to change something in our tools to prevent it.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 60 points

    Hi George,

    I'm manually building with my own makefile on the command line.  The --rom_model switch was something I obviously missed when putting it together. 

    Which begs the question, are there any white papers or app notes from the compile team (which I think would be the best source) that give a comprehensive 'howto' on setting up a DOS command line based build environment?  (One for Linux too would be great!)  I've done many searches and read tons on the RTSC wiki to get to where I'm currently at, but that darn --rom_model switch got me!  I think something like this would be useful for many out there who have issue with using the Eclipse build environment with their Clearcase system.

    Thanks again,

    Dave