Code running slowly – STM32F746

[chris250]

Hi,

I am hoping to move from using the IAR IDE to Visual Studio and VisualGDB. I have read this document – https://visualgdb.com/tutorials/arm/standalone/

To port an existing STM32F746 code base from IAR to VisualGDB I have done the following:
* Create a project using the VisualGDB automated template
* Change the project to a stand alone project
* Remove the BSP code from the solution
* Add all of the existing IAR code base to the solution (but keep some VisualGDB files such as startup_stm32f746xxx.c )
* Build and run the code

The VisualGDB-generated code runs *very* slowly (4 to 5 times slower) on the hardware compared to IAR. This includes when I flash the micro with the .bin file through STLink (no debug).

Are there any other settings I have missed?

Thanks!

[chris250]

Hi,
I can’t seem to edit my post so I’ll add more information in this separate post.

My project includes interaction with a SD card. This stopped working under VisualGDB builds unless I slowed down the access rate considerably.

I have now stripped down my project so that all it does is flash an LED. This uses a local stack variable to count and toggle the output accordingly. The vast majority of the code is common between the IAR build and the VisualGDB build. The one exception is the startup file (startup_stm32f746xxx.c). I note the VisualGDB startup file does everything I would expect it to do (sysinit, clearing bss section, call to main, etc) and it looks good to me.

I have checked the contents of the RCC clocking registers following the initialisation and the results between IAR and VisualGDB are identical.

The VisualGDB build still runs a lot slower than the IAR build.

I have also tried editing my code to use the built-in BSP (not a stand-alone project). This also runs slow.

Any help is appreciated. Please let me know if you need any more information.

Thanks

[support]

Hi,

Just to double-check, you are using the optimized ‘Release’ build, right?

[chris250]

Hi,

Thanks for the reply. I have tried many different builds including Release and changing the optimisation settings.

Raising the optimisation level makes the code unstable. The LED should flash with an even duty cycle but with optimisation turned on it does not. With maximum optimisation the LED does not flash at all.

The other issue here is that I need the debug version to run at a reasonable speed. Under IAR I can run with the debugger attached and drive the SD card at high speed with no errors. This isn’t possible under VisualGDB, and I haven’t enabled the USB section of the project yet either (that also runs at High Speed under IAR debug). I am concerned that the USB timing requirements will not be met when debugging with VisualGDB.

I am unaware of how VisualGDB performs its debugging. When debugging, should I expect to experience a speed reduction of up to 3 times slower?

I am grateful for any advice. I would really like to purchase VisualGDB (I am on trial at the moment) and use it within our company as I am a big fan of Visual Studio. The VisualGDB interface is a lot nicer to use than IAR and the Visual Studio editor is epic.

Thanks again for your help.

[support]

Hi,

Unoptimized debug builds are expected to result in much slower execution time; this is by design. This is needed because the optimizer would try to place as many variables as possible into registers and will reuse the same register for a different variable once the old one is no longer needed, making it only possible to evaluate its value while it is still needed by other code. Other optimizations would make stepping less intuitive by combining reusable code fragments like the code for the ‘return’ statements. Our best advice would be to play around with the optimization setting, changing it between -O0, -Og-, -O1, -O2 and -O3. Increasing optimization will increase the speed, but make the debugging experience harder.

Regarding unstable code, most likely your code either contains a bug that corrupts memory (but is not reproduced without optimization) or relies on some assumption that does not hold with full optimization. E.g. the following code may hang in the release build because the optimizer will try to move reading of ‘done’ outside of the loop:

int done;

void InterruptHandler()
{
    done = 1;
}

int main()
{
    //...
    while (!done)
    {
    }
    
    printf("done\n");    
}

Declaring the ‘done’ variable with the ‘volatile’ keyword will solve the problem.

[chris250]

Hi

Thank you very much for you help. You are correct – it was the optimisation that was doing its job and changing the program flow. The default settings from IAR did not perform this modification and so the problem did not arise.

Your example lead me to do more reading on optimisation and its affects on programs.

I’ll be buying an Embedded license this week 🙂 Visual Studio – happy days!

[support]

No worries. Let us know if you encounter further problems and we will be happy to help.

[Author]

Posts