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/TMS320F28379S: GIU Composer application not communicating with target.

Part Number: TMS320F28379S
Other Parts Discussed in Thread: C2000WARE

Tool/software: Code Composer Studio

I know the GUI application talks to a "monitor" chunk of code that needs to run in the target. I am unable to find out exactly how to make it work. There is mention of it in the "how to" video for GUI composer but thats where it ends. I have everything working thru the cloud tools for my code as well as the application for GUI but when I start the application it is unable to talk to the target. How to I insert the "monitor" into mu code and where do I get it the source fort it?

  • David,

    If you are looking for information on how to insert monitor code into your target application, please take a look at this link:
    http://processors.wiki.ti.com/index.php/ProgramModelUart_GuiComposer

    The page is written for Gui Composer v1 , however, the example target program with integrated monitor should work the same. The main difference would be in how the GUI is constructed using the online GUI Composer vs the earlier GCv1. You can start with the example target program available in that page and then tailor it to your needs. 

    There are a couple of related threads related to this topic that might be of interest as well.

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/642395

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/640888

  • Thanks, I will do some reading. Currently it seems to me that I can get the GUI to communicate at least that what the application page is telling me. But I must not be binding the variables properly cuz nothing seems to work and I have a blinking led in the "main" loop. When the program is loaded into the flash it starts off running at a 100ms rate which is correct. Then is tries to communicate I assume to get the data for the GUI. That was failing because it said so. But I have messed with it and now that message does not appear. But that does happen is the blinking light rate changes to slower. SO something is happening just not sure what.

    This is my first time round the block with this stuff.

    Thanks for your help. I will be in touch.
  • I am not using a uart. I am expecting the XDS connection to work. Is that a good assumption? One day I will use a UART just not now. Just want to continue developing while I have easy control of variables.
  • If you are going to use XDS JTAG for communication then you do not need the "monitor" code.
    Please take a look at the tutorial here that should help you get started with an XDS example.

  • Aarti, this is not working. When starting my application It downloads my application to my target hardware OK. Then it tries to communicate and my code in the target stops running because I can see the leds stop toggling.

    Order of things that happen;

    I run the GUI application from the cloud GUI composer.
    It connects to the cloud agent and downloads the the program.
    It connects to the target and downloads to the target hardware .
    It says "flash successful".
    I see the target hardware wink the lights. This means it is operating my code properly.
    It connects to target - says hardware connected.
    My application program stops operating.

    Something real basic must be going on because it seems to be talking to my hardware just fine.

    Can u share my desktop and help me get thru this?
  • David,

    Is your program set to run from RAM or Flash? 

    There is currently a known issue in GUI Composer v2, where RAM memory is reset between the programming step and the step that starts the debug connection/data transfer. That sounds exactly like the behavior you are seeing. The workaround for this is to rebuild the program to be run out of flash memory. 

    The tutorial I linked to earlier uses a Flash based example from C2000Ware. Could you give that a try, as that would help establish a baseline working example.

  • Hello once again Aarti,

    I have been slogging my way thru this quagmire. I have managed to get a GUI connected and running with my target.
    I am using the cloud based GUI builder and CCS 8 locally on my machine to edit & compile.

    I have several questions;

    1. When I change any code in the target of course I re-compile. But the hassle happens when I want to run it with the GUI. Thru the GUI composer I am forced to "upload" the .OUT file every time I make a change because it seems to be that the cloud needs the latest application code for the target. I get that. But is there a way to have this happen automatically. Its like 10 mouse clicks to do this operation. Driving me nuts. If I use a local GUI composer instead of the cloud version does that solve the problem?

    2. Is there a version of the GUI builder I can run on my machine locally so I don't have to use the cloud services? There have been a number of times when the cloud site was down for some reason or another. I see a GUI composer but it says something about "Insta Spin" which makes me believe that is is customized for something or another. CAN I use it instead of the cloud based GUI composer. Will it work the same as the cloud version or will there be a pile of gotcha's?

    Thanks, that's all I have for now.

    Dave
  • David Petryk said:
    1. When I change any code in the target of course I re-compile. But the hassle happens when I want to run it with the GUI. Thru the GUI composer I am forced to "upload" the .OUT file every time I make a change because it seems to be that the cloud needs the latest application code for the target.

    In the GUI Composer project properties, you can set the .out file to auto-program to ensure the correct firmware is programmed each time. So even if the .out file is rebuilt, as long as the path provided in the GUI Composer project properties is pointing to the correct file, it will auto-program the latest file. 

    David Petryk said:
    2. Is there a version of the GUI builder I can run on my machine locally so I don't have to use the cloud services?

    Unfortunately no. The GUI designer is only on the Cloud. But after the design is complete, you can export the GUI to run as a standalone app or from within a CCS desktop view. The tutorial I linked to earlier covers that detail as well. 

  • I saw that switch to auto program days ago and I have mine checked. It appears to program the target which it does checked or not but it never seems to do an "upload" like the upload button does. I find if I don't click the upload button and go thru all of that then when I run the application my code changes are not present. Maybe there is something else that needs to be set somewhere?

    I am using Chrome browser. Does it need a different browser?

    Thanks.
  • I will give this a try to see if I can reproduce the behavior you are seeing. I will get back to you when I have an update.
  • David Petryk said:
    I find if I don't click the upload button and go thru all of that then when I run the application my code changes are not present.

    You are correct, the executable does need to be re-uploaded if it has changed since the previous upload. I confirmed with the GUI Composer development team that this is indeed required. We currently do not support automatically picking up the .out file from the CCS IDE, but hope to add support for this some time in the future. Sorry about the inconvenience.

  • Aarti, checking that box makes no difference.

    Maybe I have not been clear as to what is happening.

    It seems to me - The code for the target must be uploaded to the cloud so the cloud can combine it with whatever it needs for the GUI to operate. I get that and when specifying the target location you can see the upload to the cloud take place. Now the cloud has my executable. Then I run the GUI and it proceeds to erase the target and download code into it. That download contains my code and some additional stuff that it added to make the GUI operate. I got that. Then it runs properly. Wonderful.

    Tell me if my description above is correct.

    Now I change and compile my code. I re-run the GUI and my code changes are not present. I have to quit the GUI and follow the same procedure as I did the first time and press the "upload" button to once again upload the code. So I am forced into doing about 8 clicks each time I change my code.

    It appears that when that check box is checked it forces a programming cycle of the target hardware.

    I hope I am doing something wrong because this is soooooo tedious.

    Please tell me what I am doing wrong.

    Thanks, Dave
  • Dave,

    You are not doing anything wrong, and your understanding of the situation is correct. 

    As I mentioned in my previous post, the step of manually uploading the executable (as you have been doing) is in fact required each time the code changes.
    We understand and agree that it is tedious to have to do the upload again each time the code is rebuilt, and hope to make this easier in the future. However, as of now you do have to hit the "upload" button to upload the code again each time it changes. Sorry again about the inconvenience.