Microchip Graphics Composer and MCC malfunctioning when generating configuration

[manolisss]

Hello,

We are using MPLAB VS Code / MCC to develop graphics applications and we have come across an outrageous bug. We have noticed that when we change some settings in the Composer, it is not sure if MCC will update the appropriate generated files!

• Platform: MPLAB® Tools for VS Code with all extensions up to date 2026.01.28
  "hexmate": "0.2.1"
  "mplab-ai-coding-assistant": "1.2.0"
  "mplab-clangd": "1.6.0"
  "mplab-code-configurator": "0.1.6"
  "mplab-core-da": "1.7.0"
  "mplab-data-visualizer": "0.1.4"
  "mplab-extension-pack": "1.2.2"
  "mplab-extensions-core": "1.6.3"
  "mplab-extensions-platforms": "1.5.2"
  "mplab-kconfig": "1.2.0"
  "mplab-ui": "1.6.0"
  "mplabx-importer": "1.6.0"
  "runcmake": "1.6.0"
  "toolchains": "1.6.0"
• GFX: v3.16.3 (latest available on 2026.01.28)

Steps to reproduce:

1. Open Composer and change scratch buffer size, save graphics configuration and click generate on the composer.
2. Go to MCC and generate MCC configuration.
   Having the Composer open or closed didn't make any consistent difference.
   Selecting "Forced Update All" or not didn't make any consistent difference.
3. Go to Source Control and see if the scratch buffer size value has changed in file "legato_config.h" or not. Most of the times it was not changed despite the fact that closing and opening the Composer the new value had been retained.

Most of the times the value was unchanged!!!! This means that the hours we have spent tinkering with settings and assuming they have been changed were a huge waste of time...

This is a fatal flaw of the system which makes us question its reliability at the core!
Changing anything the Composer and generating the graphics configuration should guarantee that MCC will generate all the appropriate files and changes at all times! We assumed that checking "Force Update All" would ensure the generation every time but we were very surprised to see that not even that worked! MCC seemed to update the value whenever it liked.

🆘🆘🆘 This needs to be resolved ASAP!!! 🚨🚨🚨

Step 1: Change the value in the composer and generate both configurations:

Step 2: Check source control to see if the value has changed (left side is the committed file, right side is the working copy that should have been renewed)

Step 3: Repeat generation process of both configurations until the value has finally been updated...

[scottdmorgan]

What versions of the X IDE and composer?

[manolisss]

What versions of the X IDE and composer?

• Platform: MPLAB® Tools for VS Code with all extensions up to date 2026.01.28
  "hexmate": "0.2.1"
  "mplab-ai-coding-assistant": "1.2.0"
  "mplab-clangd": "1.6.0"
  "mplab-code-configurator": "0.1.6"
  "mplab-core-da": "1.7.0"
  "mplab-data-visualizer": "0.1.4"
  "mplab-extension-pack": "1.2.2"
  "mplab-extensions-core": "1.6.3"
  "mplab-extensions-platforms": "1.5.2"
  "mplab-kconfig": "1.2.0"
  "mplab-ui": "1.6.0"
  "mplabx-importer": "1.6.0"
  "runcmake": "1.6.0"
  "toolchains": "1.6.0"
• GFX: v3.16.3 (latest available on 2026.01.28)

[scottdmorgan]

I am not familiar with using MPLAB VS Code. I have MPLAB X IDE v6.30 with the latest tools (MCC v5.6.4, Microchip Graphics Composer v3.2.6) and was able to change the scratch buffer size from 256 to 300 and then after generating code it worked fine after the first try. I am guessing the VS Code isn't as well supported as the X IDE. What do you like about using VS Code and why did you decide to use it instead of MPLAB X IDE?

[manolisss]

Hi Scott,
Microchip seems to urge all users to move to VS Code asap, we interpreted this as: the bugs that you see on MPLAB X IDE will never be resolved and there is no actual support as the IDE is updated once per year.
Moving on from that, the files do change some times for us as well so you would have to repeat the process several times to see if it is consistent. Also, I don't if the size of the project plays any part as ours is a heavy project with many screens.

[scottdmorgan]

They just released X IDE v6.30 this week so I don't see them not fixing bugs. Based on what my FAE sent me comparing VS Code to X IDE it looks like VS Code is still immature, has some limitations and is not yet mature/stable so I personally wouldn't want to use it yet for any serious development. In my opinion you are a guinea pig using VS Code for your Microchip development. Use the X IDE if you are doing serious development and move to VS Code later when it's a more mature solution. As a developer this is my opinion but let's see what the experts at Microchip have to say.

[manolisss]

X IDE is full of bugs and releasing one update per year is not acceptable to fix them. I don't know if you are a heavy user but we are champions in reporting bugs, we have reported several 6.25 issues and the response we got was "the team is focused on VS Code".
Upon downloading v6.30 we noticed that Microchip is urging users to migrate to VS Code, which obviously is not yet mature but at least shows signs of being supported. Also, it is comprised of several extensions so it is agile in terms of fixing individual bugs fast and not waiting one year.
That being said, since microchip released MPLAB VS Code and pushes people toward it, they should make sure that things like this work properly and that is why we are posting this issue.

[MicrochipGraphicsSuite]

@manolisss, Thank you for your detailed feedback. We really appreciate it. We are aware of this problem and have a fix for this in the Composer. We are planning to release this in gfx-3.16.4.

We are developing a workaround you can use for gfx-3.16.3. We will be posting it later this week.

I apologize for the inconvenience it has caused you.

[manolisss]

@MicrochipGraphicsSuite thank you for the prompt reply, indeed we were very upset when we realized that we spent hours tinkering with the library without having the settings being updated each time...
We are standing by both for the workaround and the fix.
What would make everyone's life easier would be to have a mailing list for each library where you could send things like this so that the least amount of people end up cursing Microchip and waisting their time. As soon as something like this becomes knowledge for your team you could fire an email to let subscribed users know about it. Believe me it would be much appreciated and beneficial for improving Microchip's reputation among developers.

[manolisss]

@MicrochipGraphicsSuite do you know if this issue affects also MCC in MPLAB X IDE v6.30? What we are noticing is that after generating a few configuration through the composer and then MCC, MCC never opens again and requires a clean install. Is there something we can do to mitigate this error, for example should the composer be closed when we are doing an MCC configuration generation? As a general rule it is always open in the background as we tinker we settings, screens, etc...

[microchip-graphics]

Hello,

Here is a workaround to the issue of changes in Composer not being transferred into the source files. The goal is to run standalone Composer outside of MCC, generate code to an unzipped folder, and copy this output into the source directory of your project.

Step 1:

Make sure that the Composer launched from MCC is closed.

Step 2:

Find the Composer executable on your system. This should be in your .mcc directory.
For example: C:\Users\Username\.mcc\HarmonyContent\gfx\middleware\legato\composer\windows\composer.exe

Launch Composer from this location.

Step 3:

Click "Load an existing design" or "open", then open your Composer <configuration>_design.zip.

Step 4:

Once you have opened your design, navigate to Project > Project Settings > Code Generator

Step 5:

Choose a location of where you want to generate code and leave the Generate Name blank.

Step 6:

Click Generate Code in Composer. In a file explorer, navigate to the path you selected and see that a generate_output directory exists here.
When you open this directory, you should see two items:

1. generated/
2. legato_config.h

Verify that your changes have taken place by inspecting the header.

ℹ️ Typically, these items exist inside a file called .legato_generate_cache.zip inside of the .mcc directory. The issue that you are having is likely a bug with how the paths for MCC are configured in some cases.

This seems to be more likely with a new VSCode project than an existing MPLABX project.

This leads to MCC being unable to generate the .legato_generate_cache.zip, preventing it from updating your code.

Step 7:

After verifying that legato_config.h looks like what you expect, save your Composer design. This will make sure the custom path you entered will exist the next time you open your design via standalone Composer in Step 2.

Copy the two items, the generated/ directory and legato_config.h, into your project's source directory. This should look something like project_directory/my_mcc_config/src/config/default/gfx

Copying the two items to this location will overwrite the existing generated/ and legato_config.h.

Conclusion

This workaround bypasses the issue of MCC not updating the Legato generated code.

Make sure you keep the code generated by standalone Composer. If you accidentally run Composer via MCC and generate, and it overwrites what's in your project, you can always copy the code back from the custom folder that you made.

Please let us know if you have any questions or run into further issues.

[manolisss]

@microchip-graphics thank you for the workaround, it is a bit too many steps to do when generating a new graphics configuration often. Do you have any indication when the next version of gfx will be released where this will be fixed?

[microchip-graphics]

Our target for the 3.16.4 release is the end of March.

Additional information that we have found regarding this issue:

The VSCode MPLAB MCC extension sometimes fails to unlock the .legato_generate_cache.zip file after it generates. This prevents Composer from writing your changes to the file the next time MCC generates, which prevents MCC from receiving the data it needs to update your source code.

On our test machine, it seems like MCC is able to unlock this file after every-other generate, but it may be more or less frequent on other machines.

[manolisss]

Hello,

We are having another gfx-related issue in MPLAB X IDE v6.30 which we also had in v6.25.
It seems that some times after a MGC config generation, the IDE becomes stuck in several ways:

• Parser stops working
• Color coding stops working
• Autocomplete stops working
• Navigator stops working
• Subsequent MGC config generations seem to have to effect
• IDE stuck on "check for external changes"
• After shutting down the IDE, the task is still stuck and lingering in task manager

These are just the noticeable malfunctions, we do not know what else could be going on...
Is this issue related with the above malfunction or is it unrelated? In any case it needs to be looked into by the gfx team.

GFX: v3.16.3 (latest available on 2026.02.12)

messages.log
MPLABXLog.xml

[microchip-graphics]

This issue is unrelated to the previous one.

To debug this different issue, try temporarily removing the Legato MCC Module from your MCC layout.
Before doing so, take note of the Legato module's properties (RTOS Settings) so that you can reapply them after re-adding Legato.

With Legato removed, generate as usual, and see if the issue persists. After testing this, you can add Legato back into your MCC layout and reconnect it.

Disabling the Live Parser in MPLABX may also improve performance. https://support.microchip.com/s/article/Disabling-Live-parser

[manolisss]

Let me clarify that the configuration generation that causes the issue is the one from MGC (Graphics Composer).
Your suggestion is to:

1. Open MCC
2. Open MGC
3. With MGC left open, remove legato from MCC ?
4. Generate MGC config and see if the IDE's parser gets stuck?