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/F28M36H33B2: GC-1133 bug fixed, but still have same problem

Part Number: F28M36H33B2
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

This is related to the thread where I had the problem of GC stopping my target application when connecting via TI Cloud Agent..

According to the Bug Report GC-1133 it has been fixed, but I am still experiencing the same problem. As soon as GC says "Connected to target. Hardware Connected." my application stops. I have updated TI Cloud Agent. Do I need to update anything else to get the bug fix?  

  • Depending on when your GUI Composer project was originally created, it may have needed to go through an update to work with the latest version of GUI Composer. But if that was required it would have prompted you to update when you opened the project. Other than that I don't think anything else should be necessary. 

    Are you running a program that loads to RAM? Could you summarize the current status and behavior you are seeing and I will see if I can reproduce it.

  • Yes I am running from RAM. But I seem to have figured out the issue for the running from RAM case. I did not select Auto Program in the settings, I did the programming manually. I Started the Gui and then clicked File/Program Device, after which it programmed and then paused as soon as it connected. But now if I check the Auto Program checkbox in settings before I start the gui, it works fine and runs the Gui without stopping the application. However, I still don't get it working when the program is running from flash. I'm not sure what the correct procedure is if my target is already flashed and running the application. When I start the Gui, it connects to hardware and then stops the application. How can I get it working when running from flash, since this is how it will be operating once it is put to use with the stand-alone Gui application?

  • Albert Smit said:
    However, I still don't get it working when the program is running from flash.

    I know I have had programs in Flash work fine before but it has been a few months since I have tried it out. I will give this a try again next week and get back with my results.

  • Albert Smit said:
    I'm not sure what the correct procedure is if my target is already flashed and running the application. When I start the Gui, it connects to hardware and then stops the application. How can I get it working when running from flash, since this is how it will be operating once it is put to use with the stand-alone Gui application?

    I just tried out a Flash application on a F28379D Launchpad and the GUI connects to the device and works as expected (does not stop the application). I know you are working with a different device. I will try to locate an F28M36 to test with but I from what I see so far GUI Composer is working fine when running from Flash. 

    Is it possible that you still have the workarounds that were suggested earlier in place and that may be impacting the current operation?

  • Nope, the workarounds are not present anymore. Is it perhaps to do with the fact that F28M36 is a duel core device? I am only connecting to the M3 though. 

  • So you are only loading code to the Flash of the M3 not the F28, and the GUI is only communicating with the M3?

  • Albert,

    I was able to get GUI Composer working with the M3 on my F28M35 Control card.

    Here are details about my simple test:

    1) I used the blinky examples (blinky_dc_m3 and blinky_dc_c28) from C:\ti\controlSUITE\device_support\f28m35x\v220\F28M35x_examples_Dual\blinky

    2) Built the Flash build configuration of blinky_dc_m3 after making this small edit to the code:
     - added a variable count: volatile unsigned long count = 0;
     - incremented count after LED turns on: 
       

    while(1)
    {
    //
    // Turn on the LED.
    //
    GPIOPinWrite(LED_1_BASE, LED_1_PIN, 0);
    //
    // Delay for a bit.
    //
    for(ulLoop = 0; ulLoop < 2000000; ulLoop++)
    {
    }
    count++;
    //
    // Turn off the LED.
    //
    GPIOPinWrite(LED_1_BASE, LED_1_PIN, ~0);
    //
    // Delay for a bit.
    //
    for(ulLoop = 0; ulLoop < 2000000; ulLoop++)
    {
    }
    }

    3) Built the project and loaded it to the M3 using CCS.

    4) From CCS Debug view, disconnected the M3 target. LED is now blinking on the M3 device.

    5) Power cycled the board to let the program boot from Flash and run. Blinking LED confirms program is running.

    6) Created a simple GUI with a number box widget that binds to variable "count".

    7) Ran the GUI app and observed that the widget increments in sync with the LED blinks.

    Could you try a procedure similar to this and see if it works for you?

  • Ok, I tried the blinky project and it worked fine. It also worked with my own Gui. So there must be something different with my project, but what? I have also noticed that if I flash the Blinky project in CCS and then click Run, the program starts running as expected. But if I flash my project in CCS and then click run, it does not start, I have to power cycle to get it starting after a flash load. Could this be a related issue or give a cue to the problem?

  • Albert Smit said:
    But if I flash my project in CCS and then click run, it does not start, I have to power cycle to get it starting after a flash load.

    Maybe it is related to this comment I found in the blinky example source file:

    //! This Dual Core Blinky Example demonstrates how to run and
    //! implement a standalone application on both cores. Due to an errata in
    //! the bootROM, this example may not run correctly with the debugger connected.
    //! To run the example, program both cores with their respective project and
    //! then disconnect the debugger. Set SW3 switch 1 to the down position
    //! (disconnect TRSTn) as well as setting all 4 switches on SW1 to the down
    //! position. Cycle power and both LEDs should begin to blink.

    Other than that I can't really tell what could be different in your project. Perhaps try starting with a working example project and then slowly add your code/source files into it.

  • Wait, I realized now that I did the test with the single core m3 blinky project which worked and did not stop the application upon connect. But when I do the test with the duel core m3/c28 blinky project I get the same problem as with my project, as soon as the gui connects the LED stops blinking. So now my project is completely  out of the loop. This is with the standard duel core blinky project and a new empty Gui composer project. There is something different in the duel core blinky project which causes this problem. My project was actually originally built from the duel core blinky project. So I must have inherited this problem from there. If it is due to that errata mentioned in the commented paragraph, it means that gui composer cannot connect to a duel core target running from flash when using the XDS debugger?

    Running from RAM works fine, but the problem is that Gui composer can only load one core (M3), and the C28 does not get loaded. So then my application does not work since I use both cores. The Gui only needs to connect to M3 to get the binded variables but I still need the C28 to run to do certain tasks. This is the reason I wanted to connect the gui composer while both cores are already loaded and running from flash. I cannot pre-load the C28 with the flash program and then only load the M3 to Ram because the M3 needs to startup first before the C28 can run.

    My workaround is to export the gui to CCS desktop view, load the program to RAM in CCS to both cores and then connect the gui to the M3 and test it within CCS. This makes developing a gui very difficult since I have to do this whole process every time that I make a small change to the gui.

    Is there a way that gui composer can load the program into RAM for both cores, M3 and C28? 

  • Albert,

    Albert Smit said:
    Is there a way that gui composer can load the program into RAM for both cores, M3 and C28?


    Unfortunately this is currently not supported.

    I think this issue is unique to running code on both cores of the F28M3x because of boot method on this device. I am not a device expert, but here is my understanding of the current behavior.

    The "Flash" configuration of the dual core blinky project works when the CCS debugger is connected. Here the user controls the program load and run. This works in CCS, however is a challenge with GUI Composer because GC does not support loading to multiple cores. The "Flash-standalone" configuration is designed to work in stand-alone mode upon device power up, but stops to run once the debugger/GUI Composer connects to it.

    Your workaround seems to be the only way to get it going for now, but I do understand it is very cumbersome and apologize for the lack of a better solution.

    I will see if I can get any additional ideas from the C2000 device experts that might enable a better solution, and if I do I will post an update here.