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/MSP432E401Y: ".launch" file includes a global path on CCS9.0.1

Part Number: MSP432E401Y
Other Parts Discussed in Thread: CCSTUDIO, TMS320F28379S

Tool/software: Code Composer Studio

Hi,

I'm experiencing an issue moving from Code Composer 8.0.0 to Code Composer 9.0.1.

I need to commit in SVN the ".launch" file of my project, since the flash must not be erased completely before flashing the new image. So the flash setting of MSP432 has to be set to "Erase and download necessary segments only".

The project I'm working on has two daisychained processors, a TMS320F28076  and a MSP432E401Y.

Using Code Composer 8.0.0, a .launch file was generated that did not include any global path. 

Using Code Composer 9.0.1, a .launch file is generated that includes the global path of the configuration file, like this:

<stringAttribute key="com.ti.ccstudio.debug.debugModel.ATTR_DEBUGGER_PROPERTIES.C:\Users\luca.ortu\workspace_v8\\PrjHmi\targetConfigs\TMS320F28379S.ccxml.Texas Instruments XDS100v2 USB Debug Probe_0/CORTEX_M4_0" value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot; ?&gt;&#10;&lt;PropertyValues&gt;&#10;&#10; &lt;property id=&quot;FlashEraseSelection&quot;&gt;&#10; &lt;curValue&gt;Erase and download necessary segments only&lt;/curValue&gt;&#10; &lt;/property&gt;&#10;&#10;&lt;/PropertyValues&gt;&#10;"/>

This is not ok for our needs, since we need to store this file on SVN, so a global path should not appear.

If I open with Code Composer 9.0.1 the project with the .launch file created with Code Composer 8.0.0 (with no global paths), the flash erase option in .launch file is not read correctly (I see it set to default value) and setting the flash erase attribute, a new line is generated in the .launch file, such the one that I've pasted above.

If I delete the old launch file and create it from scratch, the same line with a global path is created.

I've read this post in the forum, that seems to address my problem: https://e2e.ti.com/support/tools/ccs/f/81/t/407723

And this guide: http://processors.wiki.ti.com/index.php/Debug_Handbook_for_CCS#Debug_configurations

But I'm not able to avoid the generation of the line with the global path, even using "${target_config_active_default:nameofmyproject}".

Maybe I'm not setting this string in the correct place? I've tried to set it directly in the launch file and in the Run->DebugConfigurations menu.

I include the .launch file working with Code Composer 8.0.0 and the .launch file generated (from scratch or starting from the .launch file generated by Code Composer 8.0.0)  by Code Composer 9.0.1

Regards,

Luca

PrjHmi_CCS9.launch.datPrjHmi_CCS8.launch.dat

  • Hi Luca,

    I believe there have been several updates to how launch configurations worked between CCSv8.0 and CCSv9.0. This likely contributed to the differences you see. I will need to loop in an expert to comment further

    Thanks

    ki

  • Hi Ki,

    Ok, 

    Just to make it simpler: we are looking for a way, using Code Composer 9, to create a .launch file that does not contain any absolute path. The .launch has to be versioned because it contains the info not to erase the whole flash before flashing.

    Thanks 

  • Hi Luca,

    As a bit of background, we did change the way that CPU-specific attributes were keyed in the Launch/Debug Configuration (.launch file), since CCS 8.2.

    Such attributes in the .launch used to be keyed:
    <attribute name>.<connection name>/<CPU name>

    Some customers were having issues when they were changing between multiple Target Configuration (.ccxml) files, for a single project. Configurations made to the .launch were affecting multiple CCXML files that used the same connection/CPU name.

    The fix for this was to make CPU-specific attributes in the .launch, also be CCXML-specific. After the change, CPU-specific attributes are now keyed:
    <attribute name>.<CCXML path>.<connection name>/<CPU name>

    The tradeoff here is that .launch files became less portable.

    However, also since CCS 8.2, "old-format" attributes in the .launch are automatically parsed and upconverted to the "new-format". This upconversion is triggered when launching a debug session or opening the Debug Configurations window with the .launch. Upconversion requires that the <connection name> and <CPU name> in the old-format .launch attribute match those in your active CCXML.

    As such, here is a work-around that I believe would satisfy your use-case.

    1. Import your project into CCS 9.0, delete any old .launch file. Launch a debug session with your project to generate a new .launch file.
    2. Open the Debug Configurations window, and modify your project's .launch settings as needed. Apply and close.
    3. Open the .launch file in a text editor of your choice. Modify the key of each CPU-specific attribute, to delete the ".<CCXML path>" portion. Save your .launch file. Also save a copy of the file elsewhere, as a backup.
    4. Test that CCS 9.0 correctly parses/upconverts the old-format attributes, e.g. by checking Debug Configurations > your .launch > Target > MSP432 Settings > Erase Configuration. All the old-format attributes are already upconverted in your .launch; thankfully you have a backup copy of the modified .launch.
    5. Store your modified old-format .launch file on SVN. On first use, CCS 9.0 will parse/upconvert the old-format settings in the .launch.
    6. Important: Direct any users NOT to recommit the upconverted .launch file to SVN, as it is not portable.

    I tested this on CCS 9.0.1 with an example project using the MSP432P4111 LaunchPad. Manually creating an old-format .launch setting of "Erase and download necessary segments only", this is correctly parsed/upconverted. Let me know if you have any questions or run into any issues.

    Thanks,
    Ryan

  • Hi Ryan,

    Thanks,

    In these few days, waiting for your feedback, I found out the workaround you mention and I confirm that it works fine.

    I was wondering if we could find a way to make the .launch file completely portable as in CCS8, since, as you point out in step 6, developers must pay attention not to commit the .launch file and it is easy to forget about this.

    Anyway, I see the motivations of this change. We will use the workaround.

    Regards,

    Luca

  • Hi Luca,

    Thanks for following up. I'm glad to hear that this is working for you.

    Regarding improving the portability of .launch files, there are improvements that we've been thinking about recently.

    Best regards,
    Ryan