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/TM4C1294NCPDT: How to make GUI launcher seamless, not loading (appProgram.out) each time connect with a running application?

Guru 55913 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: MOTORWARE, LM3S8971,

Tool/software: Code Composer Studio

It would seem the ideal method of a GUI connection should not disturb the running application to merely connect with target. 

The NDNR LM3S8971 motorware RDK packaged GUI with TI logo uses high speed seamless Ethernet controls. TI never gave us the GUI source code order to update/debug or add more widgets. The TM4C1294NCPDT loves his newer fancy looking GCv1 GUI since the application now enjoys IOT cloud status reports and fancy digital controls with cool LED bar graphs.

The Ethernet GUI user can connect at anytime to a running application without disturbing the PWM, ADC, GPTM peripherals that may be tasking loads but is sadly without IOT status widgets. That said a GCv1 GUI of similar Ethernet controls will be distributed to KickStarter pledgers for application demonstration purposes. Removing the application load directive from (appInitScript.js) allows re-connection with the running application but halts the application previously loaded with (appProgram.out) file.

GCv1 seamless connection to DAP doesn't crash the running application since it continues to run from point MCU halted after closing the launcher. That seems to indicate a seamless connection to JTAG is plausible.

What code must be modified or added into existing scripts in order a seamless target connection using JTAG can become reality?

  • I must say that I am a bit confused by your post. Neither GCv1 or GCv2 support Ethernet...at least not at this point. It is possible that that the GUI application that you are referring to is not using GUI Composer.

    For Tiva devices (if they are using ICDI Debug Probe) non-intrusive(i.e. while device is executing a program) memory access is always done through DAP. If you removed this line "session.memory.loadProgram(appProgramFile /* internal variable */);" from appInitScript.js then you are correct that you have stopped the firmware from being downloaded to the device. However, this also removes the process of loading symbols that are contained in that file. Those symbols is what GC uses to figure out how much memory to read to update widgets. Your widgets should then have red X errors as that symbol resolution can not be done.

    If you did not want to download the program but still have the symbol resolution take place, then you would need to replace the loadProgram step by load symbols. The exact command would be

    session.symbol.load(appProgramFile /* internal variable */);

    You may have already done this, but I wanted to eliminate some options.

    Martin
  • MartinS said:
    Neither GCv1 or GCv2 support Ethernet...

    Point is we can not redistribute controls limited vendor Ethernet GUI thus forced to use GCv1 GUI.

    MartinS said:
    Your widgets should then have red X errors

    There are not red X next to any widget making it seem as if it should be working.

    MartinS said:
    this also removes the process of loading symbols

    Oddly the red X (missing) make it seem Symbols likely still exist in SRAM since the launch pad is still executing the code and only the launcher detached from the DAP when we close it.

  • Symbols never get transferred to the device using either CCS or GUI Composer, they are only loaded in memory on the PC. Thus they definitely are not being obtained from SRAM or any other device memory. 

    Is it possible for you to share your GC application? or send it to me privately?

    martin

  • MartinS said:
    Symbols never get transferred to the device using either CCS or GUI Composer

    Was referring to the Runtime GUI launcher reference to the red (x) not CCS.

    MartinS said:
    they are only loaded in memory on the PC

    Oddly (launcher.exe) was re-connecting to target without loading the symbols but there was no activity and no red (x) next to each widget.

    Symbol load directive now allows re-connecting without reloading the application each time. However several content pain (tabs) read only (RO) Boolean's are not in same state they were in prior to closing the launcher. Other words a user could cause catastrophic target behavior by changing a control that should be RO state as it was prior to closing the launcher. Good thing this is only a demo but want to start thinking how to get new future GCv2 GUI to work seamless as the Ethernet GUI now does.

    Thanks Martin your a genius!

  • BP101 said:
    could cause catastrophic target behavior by changing a control that should be RO state

    Fixed by binding (Receive_Value) for a pre/post processing function to the content pane RO Boolean attribute.

  • MartinS said:
    I must say that I am a bit confused by your post. Neither GCv1 or GCv2 support Ethernet

    Below is the high speed Ethernet GUI I was referring to above post, have no source codes to modify the look or controls. Notice the Scope widgets have more than one trace color. For some reason GCv1 scope widgets only produce a cyan colored trace even when forced to use basic colors such as red, black, blue.

  • Yes, this app does not look like a GC based application. If I had to guess it looks like a windows specific application that was created with MS Visual Studio. 

    When you say scope do you mean LineGraph widget? When you select a graph widget , there is a property page on the right hand side that allows you to enter variables to be graphed. That property page has a number of tabs, the tab where you enter variable names is called "Binding". If you click on "Widget" tab, then you should be able to pick which color to use for each Series being graphed. Or have you already done this and it is not working?

    Martin

  • MartinS said:
    Yes, this app does not look like a GC based application

    Tools/bin folder Stellarisware 10636 (Logger.exe) GUI is very similar to the scope widgets above GUI. That logger project build requires we run Cygwin compile in a CMD window to build a Fluid GUI you see in post above. I actually got the Logger project Fluid GUI to fully compile via Cygwin but the project had some issues with the target and I was new bee to CCS few years ago when attempted. The actual GUI builder Fluid is located under 3rdParty/Windows/fltk-1.1.10/fluid

    MartinS said:
    Or have you already done this and it is not working?

    Exactly the color is always cyan no matter what color is selected for (Value 0 Label / Color) which becomes the trace and Legend colors. Oddly the Launcher Icon has the same cyan color on the cube centers.

  • Value 0 Label would only affect the label color. I think you need to set "Series 0 Color" to change the line being drawn on the graph.
  • MartinS said:
    I think you need to set "Series 0 Color" to change

    Correct I meant to type color not label, as you see below the color has no effect in the widget. Label color is the same as widget title but the label text does not take up top grid space leaving more grid space. Notice the line thickness of the trace is barely visible even with the black background.

  • Live testing with DC inverter proved GCv1 operation is not so seamless as hopped it might be. Great for a demo of useless functionality, no one burns their fingers from hot molten solder.

    Opening/closing GCv1 GUI or loading symbols only momentarily disrupts the PWM peripheral. Often that ends in faulted target and has little real world benefit that a user must know Not to close/open the GUI when the target system is running or catastrophic conditions can occur.

    Perhaps GCv2 overcomes these severe limitations?
  • I checked with couple of people on this. This appears to be a device limitation. It does not seem to support ability to connect through JTAG without halting the CPU. This behaviour should be the same regardless of whether you are using CCS Desktop or GUI Composer (v1 or v2). C2000 devices do support this functionality.

    One alternative might be to use a target monitor in your program that uses UART, this should give you access without halting the CPU. It does require including that monitor in your target program and availability of a UART. Below link shows the solution for an MSP device and a C2000 device. However, the monitor code is just C code, thus in theory it should be relatively easy to integrate, assuming you already have code the UART.

    processors.wiki.ti.com/.../ProgramModelUart_GuiComposer


    Martin