• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 84 subscribers
  • Views 4620 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.

Random ESTOP0 instruction?

Kenneth Miller
Prodigy 40 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi All,

I'm working on a project for the F2808 and for some reason CCS seems to insert a random ESTOP0 instruction in my code. This is very inconvenient as I don't understand why it's appearing and keeps me from doing any sort of useful debug. It does appear to be machine dependent.

I've attached a screen shot that shows the C function, disassembly, stack trace, etc.

Please let me know what you think.

- Ken

 

  • 0
    Prodigy 40 points

    Also,

    This only occurs with the project on my Laptop. This doesn't happen on my desktop.

    Desktop CCS Version: 4.1.3.00038

    Laptop CCS Version: 4.2.0.10018

    - Ken

  • 0 in reply to Kenneth Miller
    TI__Guru* 89465 points

    Kenneth Miller said:

    Also,

    This only occurs with the project on my Laptop. This doesn't happen on my desktop.

    Desktop CCS Version: 4.1.3.00038

    Laptop CCS Version: 4.2.0.10018

    - Ken

    Ken,

    Very odd.. on 280x that address is in Flash so the debugger can not set a software breakpoint there (an ESTOP0 instruction).  CCS would have to use a hardware breakpoint which doesn't show up as an instruction.   So it seems the instruction is in the code itself.

    Are the compiler versions different?  (the compiler version will be noted at the top of the map file).

    Is there an asm("    ESTOP0"); anywhere in the code?  I don't see one in the screen shot, but I wonder if the compiler is moving one around from somewhere not shown.

    -Lori

     

     

  • 0 in reply to Lori Heustess
    Prodigy 40 points

    Lori,

    Yes, this is why I'm also so confused. Not matter what horrible things (stack overflow, etc) happen in RAM an instruction in the flash should not be changed. It's almost like the compiler is producing this, it's also always in the same place. The map file doesn't seem to list the compiler version, just the linker.

     

    Laptop:

    TMS320C2000 Linker PC v5.2.6

    Desktop:

    TMS320C2000 Linker PC v.5.2.6

    They appear to be the same version.

    - Ken

  • 0 in reply to Kenneth Miller
    TI__Guru* 89465 points

    Kenneth Miller said:
    Yes, this is why I'm also so confused. Not matter what horrible things (stack overflow, etc) happen in RAM an instruction in the flash should not be changed. It's almost like the compiler is producing this, it's also always in the same place. The map file doesn't seem to list the compiler version, just the linker.

    I agree it is confusing.  The linker version is also the compiler version.  Thanks for checking that they are the same version.  There is a 5.2.8 out by the way that will have bug fixes over what you are using.

    Some debug thoughts - none of which give an answer in themselves but may point to something to look at:

    • If you take the .out file from the one that doesn't work and flash it on the setup that does work, is there any change?
    • In both setups is it the same 280x device or does that differ as well?

    -Lori

     

  • 0 in reply to Lori Heustess
    Expert 2355 points

    If you read the assembly carefully you will find it is a bit out of sync with the C code in the disassembly.  The assembly code from 0x3F2090 to 0x3F2095 is lines 222 to 223 of the C code which basically says if the the length of the string is greater than 10 "FAIL;" (ESTOP0).  This is what the assembly says.  Basically the ESTOP0 is being compiled from your C code.

    Concisely, the ESTOP0 code relates to the FAIL in line 223 of the C code.  I have no experience with the FAIL command, it may be one of your defines or it may be something in CCS which is being compiled differently between versions.

    On the plus side, that ESTOP0 should never be reached unless your string is too long.

     

    Tim

  • 0 in reply to Tim King61612
    Intellectual 325 points

    Hi, Did you find out what causes the ESTOP0 problem/how to solve it? 

    I keep having the same problem. Sometimes I can run the TMDSHVMTRPFCKIT in debug mode fine, but a lot of times, I get this error and can't run in debug mode at all.

  • 0 in reply to ytan
    Intellectual 890 points

    Hi

    I've pretty much the same problem, see:

    http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/167429.aspx#614647

    If you have a solution found I'll would be glad to hear.

    Best regards

    Matt

  • 0 in reply to Matt
    Intellectual 300 points

    Hello,

    I have the same problem. If anyone has a workaround, please let me know.

    I'm using CCSv6, a LaunchPADXL with a 28027F in debugger mode with a standard controlSUITE example. When running on the internal clock (10MHz x12 /2) I don't have this error. Running on the external clock (20MHz x6 /2) the ESTOP0 error occurs randomly.