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/LAUNCHXL-CC1310: Is it possible to view Debug Console messages on a normal terminal instead of inside CCS?

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: TM4C129ENCPDT, CC2650

Tool/software: Code Composer Studio

I found DSLite which allows me to flash images without having to go through CCS which is great for semi-automatically flashing multiple boards, but how can I grab debug console messages onto my terminal (or my custom program), eg to confirm that two boards can talk to each other over their radios?

Also, is DSLite or similar available for ARM? Can I program TI chips from eg a Raspberry Pi?

  • Hi,

    >>how can I grab debug console messages onto my terminal (or my custom program), eg to confirm that two boards can talk to each other over their radios?
    One alternative is to re-target the output of printf() messages to a UART COM port (or other device) in your board. Details are discussed in section 4.3 of the following wiki article:
    processors.wiki.ti.com/.../Tips_for_using_printf

    >>Also, is DSLite or similar available for ARM?
    An implementation of DSLite for embedded architectures is not available at this time.

    Hope this helps,
    Rafael
  • Michael Moon said:
    I found DSLite which allows me to flash images without having to go through CCS which is great for semi-automatically flashing multiple boards, but how can I grab debug console messages onto my terminal (or my custom program), eg to confirm that two boards can talk to each other over their radios?

    Loadti might be suitable for your needs.

    Out-of-the-box it should be able to display the CIO console output via JTAG as the CCS debugger does, and it can also be customised on the referenced Wiki page.

    As for selecting which launchpad to use, you can create a different ccxml file for each launchpad and in the ccxml file specify the XDS110 USB serial number of the LAUNCHXL-CC1310 launchpad to use.

  • loadti seems to be what I'm after, however it throws the following error when I try to use it:

    $ loadti.sh -c targetConfigs/CC1310F128.ccxml Debug/AmberAg_Node.out
    
    ***** DSS Generic Loader *****
    
    START: 13:30:42 GMT+0800 (CST)
    
    Configuring Debug Server for specified target...
    
    Done
    
    TARGET: Texas Instruments XDS110 USB Debug Probe_0
    
    Connecting to target...
    
    testEnv.outFiles: AmberAg_Node.out
    
    Loading AmberAg_Node.out
    
    Cortex_M3_0: GEL Output: Board Reset Complete.
    
    Done
    
    Target running...
    
    Interrupt to abort . . .
    
    SEVERE: Profile Clock event id <-1> is invalid.  Valid events are:
    
    Error code #4013, error encountered during program execution!
    
    Aborting!
    
    END: 13:31:12 GMT+0800 (CST)

    CCS, with exactly the same code and .out file, does not exhibit this problem

  • Michael Moon said:
    loadti seems to be what I'm after, however it throws the following error when I try to use it:

    Try using the -n option to loadti to disable the profile clock.

    I had the same error with loadti using CC2650 (Cortex-M3) and TM4C129ENCPDT (Cortex-M4F) devices until I used the loadti -n option. Found the answer from Running Stellaris Launchpad examples with loadti.bat

    [For Cortex-M devices the profile clock is not supported]

  • Yesss! It works with -n! Thanks :D

    One more thing I don't need CCS for, just need to work out how it converts this cfg file into code, write a proper makefile and I can finally have a more familiar (and hopefully faster) build process!

    Will the reported program load speed improvements slated to come with CCS7.2 also affect loadti? IE do they use the same backend to do the job?
  • loadti would get the same flashing speed improvements. loadti is a script that uses Debug Server Scripting. Debug Server is used by CCS. Basically it is all the same stuff.
  • Excellent, loadti is currently the primary bottleneck in my development process by a significant margin, can't wait to see how the improvements mesure up!