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

srec output of hex6x missing static initialized data

Brad Clarkson
Intellectual 350 points


I'm building an srec for a 6482 using a RAM linker model.  I recently upgraded to start using CodeGen tools v7.0.1...  and have run into a problem.

I have a structure with four unsigned shorts.  It gets statically initialized in code similiar to...   VerStruct  version = { 0x5555, 0x6666, 0x7777, 0x8888 };

In the .out file I see the 8 bytes  located at offset 0x70267 of the .out file. But in the srec, the 0x5555 value is set to 0.  The other three values are correct.

I assume this is either a bug in the linker (putting a 2 byte aligned structure on an odd boundary?) or a hex6x bug?

Two questions...

 - Am I missing something?  Should I try a newer/different version of code gen tools?

 - Where would I get a newer version of the code gen tools to try?  I only see versions through 6.1.22, here...  https://www-a.ti.com/downloads/sds_support/CodeGenerationTools.htm#C6000  (Version 7.0.1 was being passed around by others, so I'm not sure how we got it in the first place)

thanks,

Brad

  • 0
    TI__Guru* 84285 points

    Most likely, variable "version" is non-const, which means it gets initialized with a .cinit entry.  The .cinit table is normally processed at boot time to populate non-const global variables, but in RAM model, the .cinit table must be processed at load time by the loading entity.  I'm not familiar with how hex6x will handle this case.

  • 0 in reply to Archaeologist
    Intellectual 350 points

    I made it const... and that made all four values show up in the srec, but doesn't really fix my problem.

    I tried with Code Gen Tools versions  7.0.1, 7.05 and 7.29.  They all exhibited the problem.

  • 0 in reply to Brad Clarkson
    TI__Guru* 84285 points

    Can you be more specific about what bug this causes in execution of the program?

  • 0 in reply to Archaeologist
    Intellectual 350 points

    I have a software version number declared like...

    SwVersion swVersion =
    {
         //   v3,   v2,   v1,   v0
         9, 1, 2, 3
    };

    When I load the srec, swVersion.v3 is equal to 0 instead of 9.  v2, v1 and v0 are correctly set to 1, 2, 3.  So our software version is reported as 0.1.2.3 instead of 9.1.2.3.

    Its not a huge issue for the software version string, but I'm concerned there may be other places that static values are not getting initialized correctly...  and I just haven't stumbled across them yet.

    thanks, Brad

  • 0 in reply to Brad Clarkson
    TI__Guru* 84285 points

    That's really freaky,  and seems like a bug.  The initialization should be all or nothing.  Do you have a reproducible test case we can look at?

  • 0 in reply to Archaeologist
    Intellectual 350 points

    2055.DspTestBuild1.zip

    I was able to create a small project that exhibits the problem.  I attached a zip file of the project.

    In Src/Control/SystemEventManager.cpp, I declare and iniatialize swVersion.  There is another variable testSequence[] declared and initialized just before it in the file.  If I comment out the testSequence[] variable...  swVersion is done correctly.  If I leave testSequence as is, the 0x3333 in swVersion is set to 0 in the srec.

    Here is the line in the bin\DTarget\TestDsp.srec with the problem...

    S3250086946800000000000000000000000000862F40999988880000AAAA5555444400006666CF   =>  Missing the 3333

    And without the problem, if I build with testSequence commented out...

    S3250086948800000000000000014444333366665555008681E0008681E0000000000000000005  => Has the 3333

    thanks, Brad

     

  • 0 in reply to Brad Clarkson
    TI__Guru* 84285 points

    This one is weird.  So far, the problem seems to be related to memwidth=32.  The hex converter seems to be padding out individual .cinit table entries to 32 bits, which is bogus.  Try running with --verbose to see some disturbing warnings.  I'm pretty sure there's a bug here, so I've submitted SDSCM00045502 to track this issue.

  • 0 in reply to Archaeologist
    Intellectual 350 points

    Thanks for looking into it for me!

    Brad

  • 0 in reply to Brad Clarkson
    TI__Guru* 84285 points

    Okay, I've taken a good, hard look at this one.  Sorry it has taken so long to get to it.  This bug has exposed quite a few problems in the hex converter, which will be difficult to resolve in old releases.  I am researching options to resolve this issue, but a fix will not be available anytime soon.

    The bug does not occur if you use --romwidth=8 --memwidth=8.  (You would have to alter the romwidth directive in the ROM specification, or remove it).  This is the recommended mode for operating the hex converter on C6000.  Is this an acceptable workaround?