CC2652P: Using sysconfig from the CLI to generate znp.sysfg

Hey Olliver,

Here are SysConfig resources from the Code Composer Studio User's Guide and Z-Stack User's Guide.  It is possible to open the *.syscfg file in a Text Editor to make custom changes, or you can find the relevant SysConfig Module inside the SysConfig Editor.  The CCS project environment will first build SysConfig output files before building the main ZNP application project.  You can view the call to execute SysConfig from the CCS Console window.

Building file: "../znp.syscfg"
Invoking: SysConfig
"C:/ti/sysconfig_1.18.1/sysconfig_cli.bat" --script "C:/Users/a0274016/workspace_v12/znp_LP_CC2651R3SIPA_tirtos7_ticlang/znp.syscfg" -o "syscfg" -s "C:/ti/simplelink_cc13xx_cc26xx_sdk_7_40_00_77/.metadata/product.json" --compiler ticlang
Running script...

Regards,
Ryan 

I did not spot that, but did see it when (manually) compiling after doing the changes. Interestingly enough, sysconfig_cli.sh --help doesn't list '--compiler' for example.

I was calling sysconfig myself as

```

sysconfig_cli.sh --output /build/workspace/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang/ --board '/ti/boards/CC1352P_2_LAUNCHXL' --product '/build/simplelink_cc13xx_cc26xx_sdk_7_10_00_98/.metadata/product.json' --rtos 'tirtos7' /build/simplelink_cc13xx_cc26xx_sdk/source/ti/zstack/sysconfig/znp.syscfg
```

however that did not yield the same `znp.syscfg` as when doing it via a change-toggle from the IDE.

I don't have any comments on why any change inside the SysConfig Editor in CCS enacts a significant change to the *.syscfg contents.  The goal is to use the *.syscfg file as an input to build .c/.h output files which are essential for the ZNP project.  Hence using the sysconfig_cli.sh standalone is not significant unless you also plan to build the ZNP using CLI and outside of the CCS IDE.

Regards,
Ryan

my goal is indeed to build the entire znp project purely from the CLI, e.g. from a CI pipeline. To me it seems that znp.syscfg is generated twice?

First when importing the example znp project, there's some very minor (maybe just the cli.args bit) added. Next the sysconfig browser component from within eclipse/ccs does 'something' (which greatly reduces the file, and leaves only the actually used parts behind, currently, I copy (and overwrite) this file now (I can link it later once I have pushed it to the repo).

Finally, when I compile the project from the CLI, sysconfig generates files again ...

The ZNP project includes SysConfig subdirectory build instructions which executes a SysConfig build as I've previously outlined.  Thus you should be able to follow CCS command line instructions without building SysConfig separately.

Regards,
Ryan

this is all working as expected. But the generated files are different from when launching via the IDE and the Console it seems. I'll go over what you said and see if I can spot the differences.

Btw, In the ZNP project, I find only the following files:

```

znp/tirtos7/iar/znp_CC1352P_2_LAUNCHXL_tirtos7_iar.ewd
znp/tirtos7/iar/znp_CC1352P_2_LAUNCHXL_tirtos7_iar.template.eww
znp/tirtos7/iar/SysConfig_Generated_Files.ipcf
znp/tirtos7/iar/znp_CC1352P_2_LAUNCHXL_tirtos7_iar.ewp
znp/tirtos7/iar/znp_CC1352P_2_LAUNCHXL_tirtos7_iar.ipcf

znp/tirtos7/ticlang/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang.projectspec
znp/tirtos7/znp.syscfg
znp/README.html

```

Which one are you referring to  specifically? because if I remove the 'iar' related files, I end up with just the `znp.syscfg`, which is what I was referring to above, and the projectspec file.

Having now pushed my changes, I can make it very concrete. This is the file generated by eclipse UI: https://github.com/Koenkk/Z-Stack-firmware/blob/21355f8ab3d1bfaf2f42f895072591fbbc7f447b/coordinator/Z-Stack_3.x.0/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang.syscfg

And the file I have after import, after sysconfig, and after build, looks still much like: https://github.com/TexasInstruments/simplelink-zstack-examples/blob/main/examples/rtos/CC1352P_2_LAUNCHXL/zstack/znp/tirtos7/znp.syscfg

so why the difference? what magical sysconfig option is causing the change from one to the other. I'm surely missing something! And the change happens the moment I 'edit' a file in sysconfig from the IDE. Just the 'safe' action triggers this.

You will need to import znp/tirtos7/ticlang/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang.projectspec into a workspace before you are able to build it.  I recommend that you post a new thread to the Code Composer Studio Forum if you experience any issues using the CCS CLI tool.  Here are the SysConfig build options from within the projectspec which CCS will use during the project build:

        enableSysConfigTool="true"
        sysConfigBuildOptions="
            --product ${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/.metadata/product.json
            --compiler ticlang

The SysConfig behavior you are describing is typical and observed from my end.  I don't fully understand SysConfig operation, so I cannot comment on why default SimpleLink F2 SDK *.syscfg files are formatted one way but then changed after making any changes to the file within the SysConfig Editor and saving.  Changes can also be enacted when using the "Custom Board" tool from the SysConfig Board View.  It could be due to a common format system implemented for any device using SysConfig, not just SimpleLink products.  Either version results in a successful build of the ZNP project.  I would recommend that you use the "Koenkk" version for your project and use the SysConfig Editor or Text Editor to modify as necessary.  If this is not acceptable, please describe exactly what issue you experience from using this method.

Regards,
Ryan 

I'm sorry if I was not clear, but I do import the projectspec already as I wrote in my starting post.

```

eclipse -noSplash -data "/build/workspace" -application com.ti.ccstudio.apps.projectImport -ccs.location "${HOME}/examples/rtos/CC1352P_2_LAUNCHXL/zstack/znp/tirtos7/ticlang/znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang.projectspec"

```

the next step would be to run sysconfig with some magic to produce the expected file, (which I do now with a simple 'copy' of a pre-generated file, which overwrites the 'odd' (well normal one, as it looks like the template really) one.

Once that is done, I run

```

eclipse -noSplash -data "${HOME}/workspace" -application 'com.ti.ccstudio.apps.projectBuild' -ccs.projects 'znp_CC1352P_2_LAUNCHXL_tirtos7_ticlang'

```

This results in a functional binary; just that I'd like to learn how to generate the expected sysconfig file, other then opening the IDE to generate the needed file.

You can edit the *.syscfg in a Text Editor to meet your application needs, if you are not willing to open the file within the SysConfig Editor, and the SysConfig builder will then generate the output files accordingly during the projectBuild process.  You should not concern yourself specifically with the *.syscfg file format after you've chosen a working baseline version to develop from.

Regards,
Ryan

I am editing the file, its just sysconfig (in eclipse) does some magic, that I can't seem to reproduce outside (using just sysconfig). Probably requiring invocations of the tool which are not documented. I'm sure it's possible, unless sysconfig (in eclipse) upon reading the file, stores it in memory, and the moment you make a change, writes out it's memory-stored version, which is slightly processed and slightly different. I linked the differences above which shows it. E.g. the copyright header is removed, some if statements, CCFG sections are added etc when eclipse saves the file. So it does 'something'.

As I'm doing automated CI/CD builds, starting eclipse to trigger the change is not feasible.  I am currently storing the 'final generated znp.syscfg' in the repo, but I also noticed, sysconfig will happily move stuff around (switching UART0 to UART1 on the same pins, for no apparent reason. Both versions will build and run fine, as only one UART is used anyway, but these 'changes' are not sitting well with me :p) Besides, it's also the educational challange in wanting to be able to reproduce whatever the GUI is doing. Maybe that's the most important part of it all :)