LAUNCHXL-F28P65X: Warning has been appeared

Hi,

Can you please share what build configuration you are using (and also what all build configurations are available)?

Thanks, 

Ira

Hi Ira,

I am using CPU1_RAM as default.

I changed other setting CPU1_FLASH, CPU1_LAUNCHXL_RAM and CPU1_LAUNCHXL_FLASH.

I tried these approaches, but unfortunately, they did not result in any significant changes to the situation.

Best Regards,

Yuki

Hi Yuki,

What version of SysConfig are you using? Is it latest Version: 1.26.2.4477?

Thanks,

Ira

Hello Ira,

I had only installed version 1.26.0 (which came with the CCS installer).

Later, I installed version 1.26.2_4477 using the sysConfig standalone installer and applied it to CCS, but the situation remained the same.

I followed the following steps:

1. Installed the latest sysConfig and reflected it in the CCS Products.
2. Deleted the imported sample project.
3. In the Resource Explorer's Package Manager, I checked the latest SysConfig and applied it.
4. Re-imported the same sample project from the Resource Explorer.
5. When I opened the .syscfg file, the situation remained unchanged, and I was unable to select anything other than 256ZEJ.
6. When I built the project, TMS320F28P659DK-Q1 was selected.

Hi Yuki,

This procedure it correct. Have you tried using the standalone sys config tool to generate the configuration files?

1. Download and launch the standalone SysConfig tool
2. Select the C2000Ware top folder to launch C2000 SysConfig
3. Generate configuration code manually
4. Add the generated content to your C2000 project

Can you try this and let me know if you are able to see the correct package here?

Thanks,

Ira

Hi Ira,

I would like to confirm the steps you provided, as I am having trouble understanding the operations.

2 To start C2000 sysconfig, you mentioned selecting the C2000Ware top folder and launching C2000 sysconfig.

 -> Is this equivalent to selecting "Start a new Design" and choosing C2000 SysConfig as the software product, and then setting the board, device, and context before clicking the Start button?

3 Regarding generate configuration code manually,

 -> I understand that the configuration code refers to the .syscfg file generated by selecting "File" > "Save" in the C2000 sysconfig tool. Is this correct?

4 To add the generated content to C2000 project,

 -> I assume you mean importing the .syscfg file into an existing sample project in CCS. Is that correct?

When I followed these steps and opened the .syscfg file in CCS, the device selection dialog did not appear at all.

Since I experienced the same issue when trying it in the cloud version of CCS,

I suspect that it may not be a problem with my local environment.

Best Regards,

Yuki

Hi Yuki,

Thank you for your patience. I was able to see the 169NMR package by following these steps.

1. Import the project into your CCS Workspace.

2. Now if you open the .syscfg file you will get a pop up and you will be asked to choose the variant. Currently you will only be able to see one package - 256ZEJ, like this

3. Now in order to see the 169NMR package, you need to change the SysConfig flags.

4. Right Click on project in explorer -> Properties -> Tools - > SysConfig. You will see the flags mentioned. 

5. Now modify the flags to use 169NMR package. Make sure your flags are the same as below image

6. Now click on the "tick" symbol on top right to save these flags. 

7. Click on "Save and Close"

8. Rebuild the project.

9. Try to reopen the .syscfg and you should be able to see the 169NMR package now. 

Once you create your syscfg with the 169NMR package the warnings should go away.

Thanks,

Ira

Hello Ira,

I was able to select the 169NMR package using the steps you provided.

However, when I tried to use the led_ex1_blinky example, I encountered an error during the rebuild process after selecting the device, specifically in step 8.

```

[7]TypeError: Cannot read properties of undefined (reading 'components')
[8]    at scriptFunc (/home/guest/ide/default/led_ex1_blinky_res/led_ex1_blinky.syscfg:61:42)
[9]    at cb (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/pinmux/services/scripting/runScript.ts:123:13)
[10]    at withDeprecatedAccessAsync (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/pinmux/services/deprecatedAccessGuard.ts:24:16)
[11]    at runAsUserScriptAsync (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/pinmux/services/scripting/scriptingGuard.ts:93:16)
[12]    at runScripts (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/pinmux/services/scripting/runScript.ts:121:11)
[13]    at sysConfig (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/pinmux/services/scripting/runScript.ts:83:8)
[14]    at status (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/cli/cli_core.ts:103:8)
[15]    at t.runCLI (/mnt/ccs/ccs/utils/sysconfig_1.26.0/dist/webpack:/sysconfig/src/cli/runCli.ts:48:4)
[16]gmake: Target 'all' not remade because of errors.

```

Additionally, after selecting the device, I am unable to open the .syscfg file, as it displays an error message.

It appears that the SysConfig flags' settings vary depending on the imported project, resulting in different behaviors. I am unclear about what settings should be used and how they should be configured.

I would like to know the best practice for starting a project, including how to properly set up the SysConfig flags and ensure consistent behavior across different projects.

Best Regards,

Yuki

Hi Ira,

Using the steps you provided, I was able to resolve the error issues, at least for now.

However, I am concerned that there may be a mistake in the procedure for using the Project Wizard to import projects.

Hi Yuki,

I am glad that the work around was able to solve your issue for now. I will share the proper procedure to do the Sys Config migration for different packages without manually editing it in a text editor after confirming with the SysConfig team.

Thanks and Regards,

Ira

Hello Ira,

Could you please provide SysConfig team feedback, if you have?

Best Regards,

Yuki

Hi Yuki,

This is what I heard back from them. 

SysConfig used to provide zero restrictions on what business units could use as a device name.  Three years ago, SysConfig was updated to only accept GPNs.  As such, when SysConfig starts, and one of the old legacy names is supplied as the device to use (either in the project properties, or in the comments of the .syscfg script), it looks up what the equivalent GPN is and updates accordingly.

Unfortunately, there are cases where two GPNs do not differ in anything that matters to SysConfig.  As such, we have many cases where the legacy freeform name of a device maps to more than one GPN.  The dialog the user is seeing is what SysConfig presents to users in this case. 

Effectively, this user is not being asked to indicate what device they would like to use – they are being told that they imported an example which works only with a specific legacy device name/package/variant, but it now maps to multiple possible GPNs, and he must pick the one that maps to his precise device.  Hence, he is not given the option to pick a 169 pin package because the example wasn’t setup for one.

Having said this, there is a migration feature inside of SysConfig.  The customer can get this feature via the “switch” button in the device view.  That will provide complete freedom to select any GPN/package/variant that the SDK supports.  It will likely leave the user with a lot of errors to correct if the device is significantly different, but if they don’t lock down the pinmux choices, I suspect migrating to a 169 pin package will likely “just work” for what they’re trying to do.

Long term, ASM can completely eliminate this dialog, and the confusion it causes, by fixing the SDK examples to specify GPNs instead of the legacy device names.  The BU was notified of this at the time the change was rolled out.

Looks like its an issue from the SDK side with respect to how the examples are provided.

Thanks and Regards,

Ira