• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 1453 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/CCSTUDIO-C2000: Running .outs using loadti

Veena Kamath
Mastermind 32695 points

Part Number: CCSTUDIO-C2000
Other Parts Discussed in Thread: TMS320F2812

Tool/software: Code Composer Studio

Hi,

I am using loadti script for loading and running .outs from the command line. However, I see that the script never exits (unless I forcefully exit using Ctrl+C).

My main code is not in an infinite loop and on completion of main function, the code gets stuck in for loop in abort function which is part of exit function.

How do I use the script so that it exits whenever it reaches exit/abort?

Thanks,

Veena

  • 0
    Guru 92251 points

    Veena Kamath said:
    I am using loadti script for loading and running .outs from the command line. However, I see that the script never exits (unless I forcefully exit using Ctrl+C).

    Is the program running from flash on a C2000 device, and using CIO?

    Looking at at some sample programs which perform printf() and then return from main:

    1. A Cortex-A8 program produces the CIO output and then exits normally:

    ~/ti/ccs830/ccsv8/ccs_base/scripting/examples/loadti/loadti.sh -c targetConfigs/BeagleBone_Black.ccxml Debug/AM3359_struct_padding.out 

***** DSS Generic Loader *****

START: 11:04:08 GMT-0000 (GMT)

Configuring Debug Server for specified target...
Done
TARGET: Blackhawk USB560-M Emulator, 20-pin JTAG Cable
Connecting to target...
<snip, GEL script output removed>

testEnv.outFiles: Debug/AM3359_struct_padding.out
Loading Debug/AM3359_struct_padding.out
Done
Target running...
Interrupt to abort . . .
sizeof(nopack)=6
&nopack.stx=0x40305948
&nopack.pktlen=0x4030594a
&nopack.pid=0x4030594c
sizeof(packed)=4
&packed.stx=0x40305950
&packed.pktlen=0x40305951
&packed.pid=0x40305953
NORMAL COMPLETION: 1155458 cycles

END: 11:04:14 GMT-0000 (GMT)

    2. Whereas a C2000 program in flash when used with minimum loadti arguments produces no CIO output and doesn't exit until terminated with Ctrl-C:

    ~/ti/ccs830/ccsv8/ccs_base/scripting/examples/loadti/loadti.sh -c targetConfigs/TMS320F28027.ccxml Debug/TMS320F28027_printf.out 

***** DSS Generic Loader *****

START: 11:25:41 GMT-0000 (GMT)

Configuring Debug Server for specified target...
Done
TARGET: Texas Instruments XDS100v1 USB Debug Probe
Connecting to target...
testEnv.outFiles: Debug/TMS320F28027_printf.out
Loading Debug/TMS320F28027_printf.out
Done
Target running...
Interrupt to abort . . .
^C

    If the --no-profile loadti option is used then the program reports CIO output, but still has to be terminated with Ctrl-C:

    ~/ti/ccs830/ccsv8/ccs_base/scripting/examples/loadti/loadti.sh --no-profile -c targetConfigs/TMS320F28027.ccxml Debug/TMS320F28027_printf.out 

***** DSS Generic Loader *****

START: 11:27:56 GMT-0000 (GMT)

Configuring Debug Server for specified target...
Done
TARGET: Texas Instruments XDS100v1 USB Debug Probe
Connecting to target...
testEnv.outFiles: Debug/TMS320F28027_printf.out
Loading Debug/TMS320F28027_printf.out
Done
Target running...
Interrupt to abort . . .
foo is: 1
foo is: 2
^C

    I think the issue is that a C2000 devices only has two AET resources to support hardware breakpoints / the profile clock.

    If you use the loadti --no-profile option, which prevents loadti using one AET resource for the profile clock, does that allow your script to exit normally?

  • 0 in reply to Chester Gillon
    TI__Mastermind 32695 points

    The program is running from RAM and not from Flash. It uses printf function to print some results.

    I am not using any parameters to the loadti other than the .out and target ccxml.

    Thanks,

    Veena

  • 0 in reply to Veena Kamath
    Guru 92251 points

    Veena Kamath said:
    The program is running from RAM and not from Flash. It uses printf function to print some results.

    I am not using any parameters to the loadti other than the .out and target ccxml.

    I can repeat that with the ccs 8.3 loadti and a program for a TMS320F2812 which runs in RAM and uses printf, in that the program doesn't terminate at the end of main.

    Found that loadti uses the default debug properties. For a C28xx target the default AddCEXITbreakpointAfterLoad "Halt at program exit for TI compilers (requires a breakpoint)" property in ccsv8\ccs_base\DebugServer\propertyDB\PropertiesDB.xml is false.

    loadti doesn't have command line options to support changing debug properties. Therefore, created a modified version in which the run() function in loadti\main.js was modified to insert the following after the debugSession.options.setString("FileIODefaultDirectory", testEnv.fileIOFolder); call:

    	// For C2800 target override the default which doesn't set a breakpoint to halt at exit
	debugSession.options.setBoolean("AddCEXITbreakpointAfterLoad", true);

    With this modified loadti script the TMS320F2818 program running in RAM exited upon completion, after printf output had been reported:

    C:\Users\mr_halfword\workspace_v8\SPILED>loadti\loadti.bat -c targetConfigs\TMS320F2812.ccxml Debug\SpiLED.out

***** DSS Generic Loader *****

START: 15:07:19 GMT-0000 (GMT)

Configuring Debug Server for specified target...
Done
TARGET: Texas Instruments XDS100v2 USB Debug Probe
Connecting to target...
testEnv.outFiles: Debug\SpiLED.out
Loading Debug\SpiLED.out
Done
Target running...
Interrupt to abort . . .
LED = 1
LED = 2
LED = 3
LED = 4
LED = 5
LED = 6
LED = 7
LED = 8
LED = 9
NORMAL COMPLETION: 545635636 cycles

END: 15:07:42 GMT-0000 (GMT)