Other Parts Discussed in Thread: SYSCONFIG
Tool/software:
I just went and read the bug description. And this is not fixed by just " system.xml editor adds support for adding projects unbound to a core".
I have tried the suggested solution from KI's answer here. And it does add the bootloader project as a unbound project.
But it does not solve my issue.
- The bootloader is not unbound but placed on core 1, the system.xml must reflect this.
- And even thou it is marked as an unbound project the .syscfg file in the bootloader project is now included in the list of scripts that is given to sysconfig.cli
"C:/ti/commonTools/sysconfig_1.19.0.2371712/sysconfig_cli.bat" --script "D:/src//prim_CPU/Prim_CPU.syscfg" --script "D:/src/sec_CPU/Sec_CPU.syscfg" --script "D:/src//bootloader/bootloader.syscfg" -o "syscfg" -s "C:/ti/c2000Ware/C2000Ware_5_01_00_01/.metadata/sdk.json" --compiler ccs
And this does not build.
I think you need to have a solution that supports this not uncommon scenario.
- First x sectors of CPU 1 contains a bootloader, build by the bootloader project.
- Remaining sectors of CPU 1 contains application SW, build by App_cpu1 project.
- CPU 2 contains application SW, build by App_cpu2 project.
Additionally some setups might have a "bootloader" on secondary CP'U too. And this setup is also valid with more than one core.
To be clear, I don't think that system.xml should be limited to only this scenario, some setups might have more than two projects on same core a.s.o.
But this scenario would work well as a smoke test of any concepts around system.xml you come up with.
And as this is a very common setup I think this should be added to the project examples and/or be described i an application note.
Finally I think the problem around Sysconfig (described above) is a bug, and should be registered as one. While the support of more projects on same core is a feature request.
