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.

LAUNCHXL-F28379D: GUI Composer v2 problems, fixes and then more problems.

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: TMS320F28379D

Hi,

After a week(!) of digging forum, datasheets, lines of code then trial and error I have managed to partially bend GUI Composer v2 to my will. I'm writing this post so no one else has to go through my pain. There is one major problem with connection procedure - after a flash and just before connection there is a reset of microcontroller and also individually a reset of RAM. When the debugger is connected TMS320F28379D by default goes to infinite loop and never boots. There are two ways to fix this. One needs the program to reside in FLASH, but is simpler. The other fixes the problem for good.

Solution one (FLASH):

If we want to boot to FLASH while in debug EMU_KEY and EMU_BMODE values have to programmed. It can by done in CCS under Scripts->EMU Boot Mode Select, but it is done only once, resets after uC reset and doesn't help with GUI Composer v2. The fix is to add few lines of code like below:

After a GUI Composer v2 flash, the program runs for few seconds before connection and is able to load this register. After reset during connection it will boot properly. This method also helps in CCS when debugging a FLASH application which involves resets. However if the program was loaded into RAM, the content would be erased this way. It would be painful to resign from loading to RAM, because it is few times faster than loading into FLASH.

Solution two (full fix):

It requires modifying .gel file that is used by GUI Composer v2, which is located in C:\Users\YourUserName\AppData\Local\Texas Instruments\TICloudAgent\loaders\ccs_base\emulation\gel. For this uC gel file is named f28379d_cpu1. Open it with notepad and then comment out lines in OnTargetConnect() as in the image below:

This way the RAM will be intact after connection.

  • Hi Tea,

    If you are trying to connect to the device for some debug in the middle of execution, you can comment out the reset and the RAM inits to preserve the device status.

    If you are trying to execute the code after loading it, a disconnect and reconnect sequence after code load will clear the RAMs due to the RAM-INITs in the gel's OnTargetConnect(). In this case, I would not disconnect. If you need to disconnect for any reason, I agree that you need to comment out the RAM INITs. I will ask our RAM expert to add a note in the RAM chapter of the TRM saying that RAM INIT is done in the gel file (this can help users understand why their code is missing in the RAM after a disconnect/connect sequence).

    Also, note that no code should be mapped to RAM directly for a fully embedded application. Code should be loaded to Flash and copied to RAM at runtime.

    Thanks and regards,
    Vamsi
  • Hi Mr. Tea,

    As Vamsi explained, one should not connect/disconnect in middle of debug. RAMs are cleared in Gel file because even when CCS is not connected, after WD reset, RAM content will be clear by BOOTROM code. So this need to be taken care in the code itself.

    I am still not clear about the issue you are facing. Can you explain the issue little bit more.

    Regards,
    Vivek Singh
  • The issue was that Gui Composer app did a reset after loading program (the reset was not done by me). This is a workaround to fix this problem. I do not have a problem, I thought that this post may help others facing this bug in Gui application.
  • Hi Mr.Tea,

    I understand. Thank you for posting your debug resolution. I don't work for the GUI Composer team. I inquired with the GUI Composer expert - Looks like GUI Composer splits up the program loading (RAM or Flash) and debugger connection in to two tasks to provide optional program loading options regardless of target communication option.

    They are aware of this issue now. They will work to come-up with a solution for this. I will make sure that they file a ticket to track this.

    Thanks and regards,
    Vamsi
  • Hello vivek i'm facing the same problem and i commented GEL_Reset(); but gui composer is still resetting the microcontroller, i'm using 28069m with instaspin
  • Problem Solved if you are running the gui as standalone app with gui runtimev5 you need to modify the gel file in: C:\Users\username\guicomposer\runtime\gcruntime.v5\win32\deskdb\content\TICloudAgent\win\ccs_base\emulation\gel