• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 835 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.

CCS 5.4.0.00091 generating bad .out files?

Fred P
Expert 2235 points
Other Parts Discussed in Thread: TMS320F28335

I have recently upgraded CCS from 5.3.unknown to 5.4.0.00091 .

I suspect that CCS 5.4 introduces a bug in .out files generated.
That observation applies to a TMS320F28335 device programmed through JTAG by an XDS100v2.
Important enough, the source code used in that "experiment" was a previously validated code stored under source control.  No way to mess things up here.  That code IS (or was...) functional with CCS 5.3.unknown

It looks like a CCS5.4 .out file may lead the code to quickly get stuck in the ILLEGAL_ISR() trap.  Having an active watchdog obviously brings the IC into a reset loop.
Being clueless, I blindly decided to deactivate the watchdog.  Believe it or not, the code started to work as well as it was used to!!
I could then resume development and reprogrammed a few new .out files through the day until the ILLEGAL_ISR stroke back!  Without any much more good reason than in the morning, I played with the watchdog.  Guess what?  Reactivating (WDCR=0x28) the watchdog made the code to start working well again.

Note that for each time that I encountered the ILLEGAL_ISR, I have cycled power and reprogrammed the IC at least 4 times.

Not having 5.3.unknown installation at hand anymore, I have used 5.2.1.00018 to make the following observations:
Compiling the exact same project with CCS 5.2.1.0018 and 5.4.0.00091 gives two different .out files.  However (and fortunately), .hex files are identical.  CCS 5.4 basically outputs a bigger .out file but I can't tell more since it is all binary.

My main suspect is CCS 5.4 since that is the only different thing I can think of.

What is happening here????

Frédéric

  • 0
    TI__Guru**** 173310 points

    Frederic,

    We may need to do a little more investigating/debugging to figure out why the .out file generated with CCS 5.4 does not work as expected, but let me start by offering a few points here:

    The first thing to check would be to see if the project used the same compiler versions or different versions to build in the project in CCS 5.3 and 5.4. CCS 5.3.0.00090 came with C2000 compiler version 6.1.0 and CCS 5.4 comes with C2000 compiler version 6.1.3. Many times when users update their CCS version they still set their projects to use the older version of compiler tools with which the project was originally built to ensure bit-exact output . If you happen to know what version of compiler tools were used for the build in CCS 5.3, you can set the same version to be used with CCS 5.4. This wiki explains how. http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Changing_Compiler_versions

    Fred P said:
    Compiling the exact same project with CCS 5.2.1.0018 and 5.4.0.00091 gives two different .out files.  However (and fortunately), .hex files are identical.  CCS 5.4 basically outputs a bigger .out file but I can't tell more since it is all binary.

    The key is to check if both builds used the same version of compiler tools or different versions. You need to use the same version of compiler tools and same build options to ensure you get the same binary output.

    If the project/executable was working fine with CCS 5.3 but started having problems with CCS 5.4, I would suggest first trying to build the project with the same version of compiler tools as was used with 5.3. If you are not sure which version that was, start with the default that came with 5.3, ie version 6.1.0. Set the project in CCS 5.4 to use compiler 6.1.0 as explained in the above wiki link and check that that works before moving on to upgrading to the newer compiler. Then if problems start to arise, you can debug further by determining if the problem is due to a compiler issue (different/incorrect code generated) or a runtime issue.

  • 0 in reply to AartiG
    Expert 2235 points

    I have doubled checked and both .out were generated with compiler v6.1.0 .  The compiler to use is a build setting in the project file.  Upgrading to CCS 5.4 did not modify that setting although I now have the v6.1.3 available.

    I have reinstalled CCS 5.3.0.00090 along side to 5.4.0.00090 and built the project with compiler v6.1.0 .  .out files are very similar but not identical.  Sizes are exactly the same but a few bytes are different here and there.  The big difference in .out files appear to be with v5.2.1.00018 .

    That being said, latest tests I made make me think there may be something else then CCS version behind that illegal ISR problem.  I have worked with CCS v5.3.0.00090 on Friday and ran into the exact same problem with the exact same weird "solution".  When I get an illegal ISR, I comment or uncomment the watchdog activation and go on.  That makes no sense to me...

    Why it never happened before only adds to the mystery.

    Do you have any suggestion as to what else to check?

    Thanks

    Frédéric

  • 0 in reply to Fred P
    TI__Guru**** 173310 points

    Now that you have confirmed the same version of compiler tools are used for both builds and the illegal isr issue is reproducible with both CCS versions, I agree that the issue does not seem to be related to the tools.

    There is some information on the ILLEGAL isr in the wiki link below - you can try to look at the stack contents to see where the trap came from and try to narrow down the issue. Some causes are buffer overflow or anything that corrupts the code. 

    http://processors.wiki.ti.com/index.php/Interrupt_FAQ_for_C2000#The_ITRAP_Interrupt

    If you need further help with this, I would suggest starting a new post in the C2000 device forum as the experts there would be able to help better with these types of issues.

  • 0 in reply to AartiG
    Expert 2235 points

    Stack content shows a return address elsewhere in the stack (as if the caller was located into the stack! does not make sense..).  At that return address, there are only 0xFF (or 0, can't remember) around.  These are trap instructions.  No surprise it ends into illegal ISR...  The question are "who told to jump into the middle of the stack?" and "why writing or not to WDCR register somewhere at the start of main() routine has any effect on this?".

    There are some other tricks on the wilki page you refer to.  I will dig deeper into this and repost on C2000 forum afterward.

    Thanks