MSPM0G3519: SYSCONFIG generates different files from the same configuration when some entries deleted/restored

Another observation.

When I modify the name of a GPIO pin SYSCONFIG (standalone GUI) will reset its PinMux mapping. Why is it doing this?

Diego/TI,

Can we please circle back on this thread from Eugene to obtain some level of initial feedback?

TY,
CY 

Hi Eugene,
Thanks for your patience. I thought I responded to this thread. Sysconfig should regenerate the files when you modify the device's configuration. As for the modified names of the GPIO pins, this will reset the pin/GPIO naming, but it should still be the selected PAx pin.
Best Regards,
Diego Abad

Hi Diego,

The point I am trying to make here is that the same input (literally) generates different files. Changing/restoring element names should not result in observable differences? Don't you agree?

Regards,

Eugene

Hi Eugene,
Maybe I'm misinterpreting the question. When you erase and create a new GPIO in SYSCONFIG, you will see a difference since you are removing a configured PAX and adding back a new unconfigured PAX. I believe you can see these changes in the preview section in SYSCONFIG (attached image below):

Is there any specific example you can provide that could narrow down the issue? 

Best Regards,

Diego Abad

Hi Diego,

The resulting generated C/H files are different even though restored content is the same. There should be ZIP file attached to this issue ... which I do not see anymore. Attaching it again.

Regards,

Eugene6404.Sysconfig.zip

Hi Eugene,
You are using a different method to compile your .c/.h files. We recommend using the default SYSCONFIG files generated in our projects to avoid issues like the ones you are most likely seeing.

vs
Best Regards,
Diego Abad

Hi Diego,

What does compilation method have to do with generating files from Sysconfig?

The issue here is not about compilation but about the output from stand-alone Sysconfig which is different for the same configuration.

Regards,

Eugene

Hi Eugene,
Let me re-direct the question to our Sysconfig team since it seems the question towards to stand-alone Sysconfig. To my understand, the .sysconfig files we generate in our projects are tailored to our devices.

Best Regards,

Diego Abad

Hi Diego,

 Diego Abad Sajamin Is there any movement on this issue?

Regards,

Eugene

Hi Eugene,
It seems the SDTIO team has not answered this thread in a bit. Let me ask the engineer directly.

Best Regards,

Diego Abad

Hi Eugene, 

I am assuming you observing the different position of macros. Functionaly the code is the same as far as I can tell but yes it is different. 

If you invoke the command line sysconfig to generate code, then it should always be consistently generated. The difference in UI generated code has to do with sequence of when items are added and their parent containers. 

What issue is this causing? 

Martin

Hi Martin,

What you've explained is the problem, isn't it? You are stating that Sysconfig is not deterministic tool with different input generating different output. It is even more troublesome that CLI behaves differently from GUI. If different input generates differently formatted output where is the trust that tool will generate correct output at all?

Don't you think that that is huge problem for code generation tooling and has to be fixed ASAP?

Regards,

Eugene

Hi Eugene, 

I am not expert on embedded software, could you please explain why the same identical instruction in a different place within the same function is a problem? 

Martin

Hi Martin,

The obvious issue is VCS. The second issue is the ordering of generated calls. What I've observed is that Sysconfig moves peripheral initialization calls around for the same input. Does it always create valid initialization sequence? The third one is determinism. I've mentioned this before. If the tool cannot guarantee the same output, then where is the guarantee that it produces valid one at all? Have you tested all possible variations of the non-deterministic output, if this is even possible? 

Regards,

Eugene

Hi Eugene, 

Just to clarify, when you build a project (generate actual program that goes to the device) then there are no inconsistencies. The command line invocation of sysconfig that is part of project build does not have the issue that you identified. However, I'll synch up with team here on how we can resolve this. 

Martin

Hi Martin,

Thank you. Please let me know when this will be fixed.

We do not use Sysconfig from CLI. We use stand-alone version GUI and generate C/H files. Then it is compiled with our production tools. However, that is not the point. IMHO, the real issue is that there seems to be two different codegen engines in the same tool and they produce different results. That should be alarming! 

As useful as Sysconfig is it shall be deterministic and consistent in what it does. See (+) SYSCONFIG: Inconsistency between Clock Tree view and SYSCTL configuration - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums as well.

Regards,

Eugene

Hi Eugene, 

The typical flow that most customers use is to generate source code as part of the project build. When CCS project is built, the first step is to invoke sysconfig cli, this generates consistent output. The same approach is what we typically see when CCS is not used and a standalone build system is used, i.e. integrate sysconfig cli to regenerate sources during the build. 

However, your use case is definitely valid and I have filed I bug report to resolve this issue. We might not be able to get this resolved until septermber release. 

The only additional work around that I can offer, is to perform Undo/Redo actions (CTRL+ Z and CTRL + Y) prior to saving generated source files. This should also avoid the issue. 

Martin