Cube IDE - Long Loading Time with Graphics.

[Garnett.Robert]

Hi,

When debugging with Cube IDE programs without any TouchGFX graphics load quickly using the debugger typically 20 to 30 seconds. When TouchGFX is used such that the NOR Quad SPI Flash has to load the loading time can easily exceed 3 minutes. With only a singles simple screen it takes ~60 seconds.

I assumed that if nothing is changes in the graphics from one debug session to another then there would be no changes required in the external graphics flash and so the loading of this memory is unnecessary after it has been loaded once.

I therefore turned off the external loaded in the debugger setup:

However when I tried this I got the following error:

Error in final launch sequence:
 
Failed to execute MI command:
load G:\\ShorttG2\\ShorttG2\\STM32CubeIDE\\Debug\\STM32H7B3I_DISCO.elf 
 
Error message from debugger back end:
Load failed
Failed to execute MI command:
load G:\\ShorttG2\\ShorttG2\\STM32CubeIDE\\Debug\\STM32H7B3I_DISCO.elf 
 
Error message from debugger back end:
Load failed
Failed to execute MI command:
load G:\\ShorttG2\\ShorttG2\\STM32CubeIDE\\Debug\\STM32H7B3I_DISCO.elf 
 
Error message from debugger back end:
Load failed
Load failed

Would it be possible to avoid redundant graphics loads in some way to shorten up the debugging turn-around time?

To avoid the problem I have been testing backend code on a system with no graphics, however this requires double handling of the code because I then have to bolt the code into to the system complete with graphics, and then retest everything in the new environment.

Best

Regards Rob

[Garnett.Robert · Accepted solution]

I found a work around for this problem that isn't perfect as it involves "commenting out" the calls to the graphics task and the TouckGFX_Init command viz:

#define TOUCHGFX_ENABLE 1
 
#if(TOUCHGFX_ENABLE == 1)
  MX_TouchGFX_Init();
#endif
 
 
#if(TOUCHGFX_ENABLE == 1)
  GUI_TaskHandle = osThreadNew(TouchGFX_Task, NULL, &GUI_Task_attributes);
#endif

With these two functions defined out the compiler optimizes out all of the graphics code.

Of course this is only useful for debuggind processes that are independent of the graphics and may need some test code to simulate graphics input, but it does speed debug loading a lot.

It would still be nice to make graphics loading contingent upon graphics changes, but the method described here will work in a lot of situations.

[wired]

The best way to do this is to create a new launch configuration in your Run/Debug settings. In addition to my Debug configuration, I have a similar one called Debug No GUI. In this configuration, you go to the Debugger tab and uncheck the External Loader Checkbox in the Misc group (you need to scroll down to see it).

Another nice thing you can do is if you want to run the debugger in low power modes, you can Enable that in the Device Settings group on the same dialog. I actually have 4 debugging configurations:

GUI with LPM

GUI wo LPM

No GUI with LPM

No GUI wo LPM

If I have changed anything in the GUI, I simply select my 'GUI wo LPM' Launch Configuration.

[wired]

Looking closer at your post, I see you already tried that. This works fine in CubeIDE with my STM32F469i-DISCO board. Not sure why you had a problem...

[Garnett.Robert]

Hi Wired,

Thanks for that.

I'm not sure either, but I like your ideas. The workaround I have is OK. Basically I was debugging a driver I have written for the WiFi Module on the Tiny Shark. As you probably are aware debugging comms is a nightmare especially when the device data is very sketchy and when you have to write a driver on the client side as well.

So I created a project with just the WiFi, no GUI. After I got it working I had to bolt the WiFi code into the full project which was also a bit of a pain.

Such is life.

Regards

Rob

[wired]

Rob,

I thought of your problem today when I got a Failed to Execute MI command error. I sometimes get these because STM32CubeIDE has the annoying 'feature' of enabling the Resume button before you have reached your breakpoint in main(). I sometimes am not paying close attention, and hit the Resume button before the debugger has loaded the code and stopped at the first instruction in main(). This results in the MI error and the failure to debug. I then have to start all over.

I wonder if this might have happened to you?

ST, if you are reading this, could you consider not enabling the Resume button until the system is actually ready and safe to resume?