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.

F28M36H33B2: Gui composer loads target but does not run target application

Part Number: F28M36H33B2

I am using the cloud based gui composer. If I preview the gui, it connects to the hardware via cloud agent and XDS 200 and programs the target, but then the target just hangs there and does not run. If it was running before I connect, it also stops after the programming. I have seen this issue in another post (e2e.ti.com/.../601175) where they said it is a reset instruction in the gel file that causes this. I have tried to do the same and remove the reset in the gel file, but it does not help. My gel file also looks different since I am using a different device so I'm not sure if I'm changing the right thing or is it caused by something else? See attached the gel file in the folder .....\AppData\Local\Texas Instruments\TICloudAgent\loaders\ccs_base\emulation\gelf28m36h33b2_m3.gel

  • Albert,

    The file you attached has the reset removed correctly. Would question would be are we sure that is the correct GEL file? Did you check the ccxml file to see what GEL file it was referring to? Just to confirm you are loading the program to the Cortex M3 core and not the 28x core correct?

    Regards,
    John
  • Yes it is the same file that the path "initialization scrip" in the .ccxml file points to. But this is when I view the ccxml file in Desktop CCS. How do I check/set this in the cloud gui comoser? Yes I am loading it to the M3 core. 

  • If you are using that ccxml file then it should be the same GEL that is used by GUI Composer. Normally I would suggest putting something in the GEL file that would touch something that we could then view in GUI Composer but that is likely not going to work due to the other issue. I suppose you could insert a GEL_System() Command that opened notepad.exe or something like that to confirm that it is being executed. You could just put the command in the OnTargetConnect() function in the GEL file.
  • I added this line to the gel file:

    GEL_System("start C:\\users......\\test.txt")

    It works when I connect with Desktop CCS, but not with Cloud gui composer. So I suppose it does not run the correct gel file. How does Gui Composer know what ccxml file to load when I only upload the .out file? Do I have to upload the ccxml file also?

  • Albert,

    I am working on this. I have a 28M35 setup.

    John
  • Albert,

    The .ccxml gets generated on the fly in this case.

    I can confirm that the location you stated for the gel file is correct. I tried putting the GEL_System() call in there but I was not seeing the output. I enabled logging and I can confirm that it gets called so the correct file is being loaded.

    One thing that I did notice is that if the "dslite.exe" doesn't terminate after ending the GUI composer session then the GEL file is not getting reloaded. For example if you ran, then made a change to the gel file and ran again it would not pick up the change in the GEL file. For testing I checked task manager after stopping the GUI composer session and would terminate the dslite process if it was still there.

    Regards,
    John
  • Albert,

    Did you have any luck getting further with this?

    John
  • I am not sure how to go further with this. The line I inserted that opens notepad works with CCS desktop but not with the cloud GUI, so it obviously does not execute the correct gel file. I still don't understand how Cloud Gui Composer knows where to find the correct ccxml file, and by extension the correct gel file, if it is generated on the fly? I cannot find a program "dslite.exe" in my task manager so I'm not sure what to do about that.

    Also, now all of a sudden, I have another problem that keeps me from going forward with this issue. When I try to connect it gives me the message "System is already configured" and then it just hangs there. I tried to close and reset everything but it keeps giving me that message. So I can'd debug the gel file problem any further before it connects again. (I guess this is another problem and I need to open another thread, but I actually already have two other threads running with different problems I am having with Cloud Gui Composer. So a am hoping that this is an easy one to fix so that I can get back to the initial issue. Do you know why it would give me that message?)

  • Albert,

    The GEL_System() call for some reason doesn't work the same way with GUI Composer. Normally I do that notepad.exe trick but I tried it out and could not get it to work. I apologize for making that suggestion, it should work but I should have tried it before suggesting it. Instead I turned on some logging and I could see that the correct GEL file was getting loaded. Thus I believe you have edited the correct file.

    I have tried some programs on my F28M35 board. Right now I am only getting 1 update in the GUI Composer dashboard that I have for it. I created a simple one with the global variable whose value keeps changing. However the GUI only shows the value once and then it no longer updates. In CCS I see it constantly changing. I am going to add some code to blink an LED so that I can be sure it is running properly.

    John
  • Albert,

    I am now able to see exactly what you see.  (edited this line as I had a typo so it said not instead of now)

    I updated my program to Blink an LED so I could see if it was running. I am also placing it in flash.

    I launch GUI Composer. Program is running as I see the LED blinking, it flashes the program again, blinks for a bit. Then it connects again and the program stops running.

    If I do a similar sequence in CCS. Launch the debugger (which connects and programs the flash, stops at main()) if I run it works fine. If I disconnect it is still running. When I connect it it halts. I have commented out every line in the OnTargetConnect() function in the GEL file and it still halts when I connect. This is what is causing the problem. I suppose we could do something where we make the OnTargetConnect() load the program and run. I will see if anyone can figure out why the device is halting on connect.

    Regards,
    John

  • I can get the program to run or I can get GUI Composer to connect but I am not able to have it be connected and running.

    After the program is loaded it runs for a few seconds as GUI Composer disconnects after the load. But once GUI Composer connects again the program is halted. I can get it to run the program again by putting a GEL_Run() in the OnTargetConnect() function but that blocks GUI Composer from connecting properly so then the GUI doesn't get updates. I have tried a lot of different modifications to the GEL file but nothing has been successful in getting the state we need.

    John
  • Albert,

    If you are still interested in getting this working I have a solution.

    This problem has been bugging me as I could not figure out what is going on. Basically what is happening is that the component responsible for flashing is issuing a reset when it gets loaded. When using GUI composer this actually results in multiple resets happening as the component gets loaded and unloaded at different stages.

    So what I have done is cleared out pretty much everything in the GEL File. That is likely not necessary but I have been experimenting with this so much that my file is in that state.

    Then in the OnReset() function I have added a line that looks like this:
    PC = 0x00201BA4;

    Basically after a reset it is setting the program counter to the address of _c_int00
    I could not use the symbol here as the symbols are likely not loaded so I used CCS to determine the address and then entered that.

    Now GUI composer is working for me.



    We will be having more discussions on why that reset is happening and if it should be removed.

    Regards,
    John

  • Hi John

    Thanks for you reply. Yes, I still want to get this working. I was away for the holidays but back now and will try your suggestion. 

  • Albert,

    You will need to use CCS to figure out what the address of c_int00 is for your application and then adjusted the line in the GEL file to match that. It is a pain as it can change when you rebuild your program but the trick works for me.

    Regards,
    John
  • Hi JohnS

    I have implemented your suggestion of modifying the gel file with PC=c_init00. That seems to have solved the reset issue. Is this a device specific issue or a Gui composer issue. Will it be fixed? 

    Now when I connect with Gui composer and load the program the target application continues to run and I can see the values on the Gui being updated. However the values are completely random and does not make sense. It is as if the Gui widgets are linked to the wrong variables. I am not sure if this is now a separate issue and if I need to open another thread for it? It seems like this was happening even before I did the PC workaround in the gel file. The only difference is that the values are now being updated, albeit wrongly, since the target does not reset anymore and I only noticed it now. When I export the same Gui to CCS Desktop view it works perfectly, so there is nothing wrong with the Gui itself.

  • Albert,

    The issue is device specific but still is a bug. The component that does the flashing is a dll. This dll is device/family specific. When the C2000 one gets loaded it resets the device. In CCS this is not an issue as the sequence is ok as we load the program after the dll is loaded so the reset doesn't matter. With GUI composer the sequence is different and the dll ends up getting loaded again later which causes a reset to happen after the program load has occurred.

    I hit this same issue again with another user on a C2000 device. In their case they were loading the program to RAM but after reset the device was set to boot from FLASH so the wrong program would get executed. The workaround for that was that I saw a couple lines in the GEL file that were commented out:

    // EMU_BOOT_SARAM();
    // EMU_BOOT_FLASH();

    I uncommented the first one and then it would boot from RAM after reset. Unfortunately I don't see an equivalent function in the GEL file for the device you are using.

    There is a bug tracking getting rid of that reset when the dll gets loaded. That will get fixed.

    It has been a while since I have looked at this thread.
    Sounds like the device is running as you get updates in the GUI.
    Do you know if the program is working correctly? Wondering if the operation of the program is getting messed up.
    Is the program running from RAM or FLASH?

    Regards,
    John
  • It was running from RAM (I loaded the RAM .out file). When I now loaded the Flash .out file it is working. So seems like that was the problem. Strangely, the _c_init00 address that I am using in the gel file is the value that I got from loading the RAM symbols in CCS. That is why I loaded the RAM .out file onto Gui composer. Then I tried loading the Flash .out file and use the _c_init00 address value that I get from loading the Flash symbols in CCS, but it didn't work. Then I tried the _c_init00 address from the RAM symbols with the Flash .out file and that worked. So I'll just need to run from Flash then. Never the less, your workaround is working now, thanks. Where can I follow the bug fix to see when it is fixed?

    Regards

    Albert 

  • Albert,

    The bug ID is GC-1133.  There should be a bug tracking link on the right hand side when you are in the CCS forum that can be used to check status.

    Regards,

    John