TMS320F28388S: Starting the CLA

Part Number: TMS320F28388S

Greetings,

I am trying to stop the CLA the first time a task runs.  I have setup the debug configuration to attach without affecting the running system, and connect the emulator in a part of the code which does not use the CLA.  The connection to CPU1 works as expected.  But the connection to CPU1_CLA is suspended.  When I start the code I am interested in, the emulator doesn’t connect to the CLA until many occurrences of the task have occurred.  It does stop at the MDEBUGSTOP point, but not the first one.

Is there something else I need to do to have the emulator run CPU1_CLA such that it will stop on the first run of the task?

Thank you,

Ed

  • Hi Ed,

    Is this the same issue/project from (+) TMS320F28388S: CLA Halts When Attaching - Code Composer Studio forum - Code Composer StudioTm︎ - TI E2E support forums? Let's continue the discussion there to keep things concise and I will close this thread.

    Best Regards,

    Delaney

  • Hi Delaney,

    The genesis of each is the same project.  But they are different issues.  The first is the case where the system is running, and CCS is attached with a debug configuration which includes both CPU1 and CLA1.  The hope is to find a way to attach to the CLA without stopping it.  The ability to attach to all relevant cores when the system is running is vital when troubleshooting system level issues.

    In this one, the debugger is attached at a time when it doesn't matter if the CLA is halted.  CCS is then setup to break at a particular spot in a CLA task when it runs.  But it takes so long for the CLA to start, that we miss the first many runs of the task.  This ability is useful when doing initial debug of a CLA task.

    So these are two issues, both with the CLA, but using CCS in very different ways.

    Thanks,

    Ed

  • Hi Ed,

    I see, I will have a response back early next week.

    Best Regards,

    Delaney 

  • Hi Ed,

    Interesting I see, how have you verified that the debugger breakpoint isn't hit the first time? Did you toggle a GPIO in each task?

    Also, I would take a look at the gel files for this device, and your specific CCS install to see what is being run on the CLA upon a debugger connection. 

    Best Regards,

    Delaney

  • Hi Delaney,

    Yes.  I have the CLA toggle a GPIO each time the task runs.  At this time, we only have one task.  The other tasks are simply an MSTOP with the associated MNOP instructions.

    To avoid conflicts, I am currently not using any GEL scripts.

    Thanks,

    Ed

  • Hi Ed,

    The gel files get run automatically by CCS when you click on different buttons in CCS. Even if you connect "manually" by launching the target config, it will run specific gel actions functions. See gel documentation here.

    Best Regards,

    Delaney

  • Hi Delaney,

                     Thank you for the info.  There is a lot there, so I don’t know where to begin with regards to this issue.

                     I have not been using GEL files under the assumption that if none is specified, nothing would be executed.  Is that a valid assumption, or will some default things be done if I don’t specify a script?

     Thank you,

     Ed

  • Hi Ed,

    Gel files are run automatically by CCS when you press different UI buttons and are included in your CCS install. So, no gel file actually needs to be specified to run. These are basically the underlying scripts that CCS uses when you do different debugger operations. For some UI interactions the device and memories are reset, sometimes different registers are written, it all depends on the gel file function definitions for that device. I'm not sure exactly which function gets run with every UI interaction, this should be documented in the resource I provided. However, the actual function definition in the gel could differ between devices.

    Best Regards,

    Delaney

  • Hi Delaney,

                     In the past, we successfully used GEL files using CCS 10.4.0 and the 379.  But we were not using the CLA.  Those GEL files were very minimal, and did only what we needed for debugging purposes.  Still there were routines which were simply stubbed out, i.e. they did nothing but return.

                     For the CCS 12.8.1 and the 388, we don’t currently need the debugging functionality, so I have elected to simply remove the use of GEL files from the projects.  But now, because of the issues, I am wondering if doing so causes CCS to run default routines instead of doing nothing.

    Thank you,

     Ed

  • Hi Ed,

    so I have elected to simply remove the use of GEL files from the projects.

    By this, do you mean you deleted the gel files from your CCS install? If so, I'm not sure exactly how CCS would operate in that case.

    Best Regards,

    Delaney

  • Hi Delaney,

    I have removed the GEL files from the CCS project only, which leaves it with the two pictures earlier in this thread.

    Is there a minimum set of routines which a GEL file should implement?

    Thank you,

    Ed

  • Hi Ed,

    I see, sorry I was misunderstanding you before. Yes, in that case the gel functions will not run. 

    What do you have as the trigger source of your CLA task? Does that peripheral have a FREE/SOFT emulation setting?

    Best Regards,

    Delaney

  • Hi Delaney,

    It is being triggered by a peripheral which has a FREE_SOFT field.  We have set that field to 0.  I can see that the CLA runs each cycle because it toggles a GPIO within the task.

    Thanks,

    Ed

  • Hi Ed,

    Ok, I see. I will get back to you.

    Best Regards,

    Delaney