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.

Compiler/CCSTUDIO: Use of uninitialized value in join or string at /usr/lib/perl5/vendor_perl/5.22/XML/Simple.pm

Part Number: CCSTUDIO

Tool/software: TI C/C++ Compiler

We use ofd430.exe and global_types_gen.pl to produce a listing of all the structures and there offset in the program. We are using the MSP430F2618t.  It has been working, but I'm I'm trying to setup a new  test station with the latest CCS7 and tools. I run the following two lines:

First I run:

ofd430.exe -xg --xml_indent=0 --obj_display=none --dwarf_display=none,dinfo,types xPG_MicsPAD.out

which produces xPG_MicsPAD.out.xml, then I run:

global_types_gen.pl xPG_MicsPAD.out.xml

When I the global_types_gen.pl script runs it produces 20,000 lines of

Use of uninitialized value in join or string at /usr/lib/perl5/vendor_perl/5.22/XML/Simple.pm line 1284.
Use of uninitialized value $key in hash element at /usr/lib/perl5/vendor_perl/5.22/XML/Simple.pm line 1290.

I am upgrading CCS to CCS7, cg_xml to version 2.50, the perl is:

This is perl 5, version 22, subversion 2 (v5.22.2) built for cygwin-thread-multi-64int.

The lines being complained about in the perl simple.pm is join command:

join(',', @DefKeyAttr) eq join(',', @{$self->{opt}->{keyattr}});

and the web mentions that this is a warning do to undefined variables. The tools/scripts are all T1, so I'm not sure how to fix/resolve this to get rid of the errors. It's flooding are test/build logs.

I can't seem to find this specific problem or solution listed on any web or TI sites.

  • I can reproduce the problem.  I don't know what is going on.  I'll continue looking into it.

    In the meantime, considering using the binary executable form of global_types_gen.  It is in the \bin directory of the cg_xml installation.  Where you invoke global_types_gen.pl the usual Perl way, run this executable instead.  That worked for me.

    Thanks and regards,

    -George

  • George,

    Thanks for the quick reply. I did a quick test and it seems to fix it. I will kick of some more tests to run overnight  and update this thread in the morning with results.

    I didn't know there was an .exe version. It looks like there is an .exe version of each of the .pl scripts. When/why would I ever use the .pl script over the .exe. Wouldn't the .exe always be faster/better?

    Thanks,

    Curt

  • Hi George,

    I ran several tests last night and they all passed. Yes, using the .exe did resolve the problem. I am willing to call this issue closed/fixed. I would be interested in your response to why use the .pl scripts over the .exe. 

    Thanks,

    Curt

  • Curtis Lehman said:
    When/why would I ever use the .pl script over the .exe. Wouldn't the .exe always be faster/better?

    That is not the purpose of the executables.  The purpose of the executables is to give the customer something they can run immediately, without the need to install anything else.  If you all you get are the Perl scripts (the .pl files), then you have to install Perl, XML::Simple, and everything it needs, before you can start working.  To those who are familiar with Perl, this is not hard.  But to someone new to Perl, it can be a challenge.

    Thanks and regards,

    -George