• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 1170 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Unterminated .cinit section?

Jan Nárovec
Intellectual 410 points

Hello,

when trying to discover why my program isn't booting-up properly (F2812 processor, CGT 6.4.4), I've found, that the .cinit section isn't terminated properly - or did I miss something?

The data in .cinit section looks like this (extracted from HEX file):

Length: FFFE (2) Address: 003F8220 Data: 0000 0000

Lenght: FF8A (118) Address: 003F8380 Data: 0046 0069 0072 006D 0077 0061 0072 0065
0020 0032 0038 0031 0032 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0053 006B 006F 0064 0061 0020 0045 006C 0065 0063 0074 0072 0069 0063 002C 0020
0073 002E 0020 0072 002E 0020 006F 002E 0000 0000 0000 0000 0030 0038 002E 0030
0039 002E 0032 0030 0030 0037 0000 0000 0031 002E 0032 002E 0030 0033 0030 0000
005A 0061 006B 006C 0061 0064 006E 0069 0020 0070 0072 006F 0067 0072 0061 006D
006F 0076 0065 0020 0076 0079 0062 0061 0076 0065 006E 0069 0020 006A 0065 0064
006E 006F 0074 006B 0079 0020 0048 0032 0031 0030 0035 0050 0031 0000

Length: FFFE (2) Address: 003F8736 Data: 0000 0000

Lenght: FFFE (2) Address: 003F8738 Data: 0000 0000

Length: FFFE (2) Address: 003F873A Data: 1A09 003F

Length: FFFE (2) Address: 003F873C Data: 1A09 003F

Length: FFFF (1) Address: 003F872B Data: 0000

No terminating zeros follows - instead, the .switch section follows immediately after the last data word. But the rts2800 library expects the .cinit section to be terminated by zero-length entry, even the comment in boot28.inc from rts2800 sources states, that "The init table is terminated with a zero length".

Compiler options: -c -g -q -pdr -pdv -as -O1 -ml -v28 -fr"$(OBJDIR)" -ff"$(LSTDIR)" -fs"$(ASMDIR)"

Linker options: -z --disable_clink -m"./$(TARDIR)/$(PROG).map" -o"./$(TARDIR)/$(PROG).out" -stack=0x400 -w -x $(INCLIBS) $(LIBS) $(CMDFILE)

hex2000 options: -q file.out -i -memwidth 16 -romwidth 16 -map file.mpx

The .cinit record in the map file looks like this:

.cinit     0    003f2b4e    00000096     
                  003f2b4e    0000007e     mon.obj (.cinit)
                  003f2bcc    0000000a     rts2800_ml.lib : exit.obj (.cinit)
                  003f2bd6    00000005                    : _lock.obj (.cinit:__lock)
                  003f2bdb    00000005                    : _lock.obj (.cinit:__unlock)
                  003f2be0    00000004     sflash.obj (.cinit)

The length (96 (hex) = 150 (dec)) corresponds to the above data from HEX file: there are seven data blocks, each block has a three words long header, that gives 21 words for headers and 118 + 5*2 + 1 = 129 data words. When we put it together, it gives 129 + 21 = 150 words. So the map file and HEX file corresponds. But hey! Where is the terminating word?

  • 0
    TI__Guru**** 232640 points

    A correctly terminated .cinit section appears similar to this in the map file ...

    .cinit     0    00001d76    0000007d     
                  00001d76    00000031     rts2800_ml.lib : lowlev.obj (.cinit)
                  00001da7    0000002a                    : defs.obj (.cinit)
 <... many similar lines appear here ...>
                  00001ded    00000004                    : memory.obj (.cinit)
                  00001df1    00000002     --HOLE-- [fill = 0]

    Notice the HOLE on the last line.  That your map file does not show that hole is proof of the problem.  (Well, it is possible the hole is present, and the map file does not show it.  But this is unlikely.)

    We need to reproduce this ourselves in order to fix it.  Is your code organized into a CCS project?  I'd appreciate if you would attach the project to your next post.  Directions on how to package up a CCS project can be found in this post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 410 points

    3568.EXAMPLE.zip

    Hello George,

    thank you for your response. Our projects are Makefile-based, we do not use CCS. I've prepared a very simple example, hopefully it is attached to this post. The code consist from a Makefile, linker command file, and two source files located in src/ directory. The resulting files are generated to the dist directory.

    The only thing that must be changed before compiling on another machine, is the CCDIR variable defined in Makefile.def.

    I must be doing something wrong, but don't know where... For now, there is an ugly workaround: I created a section (named .cinit_terminator) containing a constant word initialized to 0, and the .cinit/.cinit_terminator sections are GROUPed together by means of the linker command file.

    Thank you,

      Jan

  • 0 in reply to Jan Nárovec
    TI__Guru**** 232640 points

    If you add --rom_model to the linker options variable LDFLAGS, then the .cinit section is correctly terminated with a 0.  I am unsure whether this is user error, or an error in the tools.  I'm looking into that.  But now you have a way to move forward.

    For background on --rom_model, please see the section titled The --rom_model and --ram_model Linker Options in the C28x assembly tools manual.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 410 points
    Thank you,

    please, let me know, if you find some further information. Anyway your suggestion works perfectly.

    Thank you once again, best regards,

    Jan
  • 0 in reply to George Mock
    TI__Guru**** 232640 points

    George Mock said:
    I am unsure whether this is user error, or an error in the tools.

    It is user error.  It turns out there is one seldom seen usage model where the compiler automatically adds the option --rom_model: If you build one or more C files and link all in the same invocation of the compiler shell.  For example ...

    % cl2000 *.c -z -o final_executable.out

    This usage model is not a common practice.  

    Otherwise, the compiler cannot know, in the general case, what kind of files are being linked.  So if you need the special linking conventions for C/C++ code, then you need to explicitly use --rom_model (or, in other rare cases not described here, --ram_model).

    Thanks and regards,

    -George