Embedded Profiler Incredibly Slow

[codex653]

Hi,

I just upgraded my license from Embedded to Custom so that I could take advantage of the performance and timing analysis features. I’ve followed the tutorials here and here, but found that the Real-Time Watch window doesn’t output performance data for the functions I’ve asked it to profile. All I have is a blank screen informing me that “No calls have been recorded for this function yet.” These functions are ones that are called many times per second and I can verify that through the use of the Chronometer, however I really would like to use the Real-Time Watch window or the Analyze Performance with GDB functionality.

When debugging under the Real-Time Watch, the GDB output window shows new logs every few seconds or so (very slow). Upon pausing the debugger, I’ll find that the code is in one of the GDB routines that sends out data over serial to the PC. No matter when I pause, restart, and pause again, I am always in some piece of code related to the GDB debugger output profiling.

 

What can I do to speed this up/make it run properly? I really need this to work for a project deadline I have coming up soon.

[support]

Hi,

The behavior you are describing could be caused by several different factors:

• USB virtualization slowing down communication with the JTAG probe
• Some very frequently called functions being configured for monitoring, overloading the communication channel
• Unexpected RTOS modifications that cause internal state corruption (real-time watch only supports FreeRTOS currently)

The easiest way to diagnose this would be if you could make a short video showing:

• Your debug settings
• The slowly updating output you mentioned
• Several seconds of the live profiling window (including the ‘statistics’ view)
• Call stack and the context (e.g. the value of s_FastSemihostingState)

This should help us quickly understand what is going on and suggest a fix. If you don’t want to make the video public, you can simply send it via our support form.

Another approach would be to try running the analysis on a “LEDBlink” project and if works normally, start comparing/eliminating the differences between the 2 projects (e.g. switch to use same RTOS, same main() function, etc).

[codex653]

I went to go try out the LEDBlink project and found that I could not check the box for “Allow tracing function calls in Real-Time Watch” under the dynamic analysis page. When I click it, the box turns slightly grey for a moment and then the entire VisualGDB project properties window crashes without applying anything.  The same thing happens when attempting to click any of the other tick boxes in that window as well.

I also opened up my slow project I originally mentioned and found that the Real-Time Watch functionality had been disabled (not by me) between when I posted the original question and now. I tried to re-enable it, but discovered that the project properties window crashed.

I tried reinstalling VisualGDB, but that did no good. What’s going on?

 

[support]

Hi,

It could be that your license upgrade did not get applied properly. Please try re-entering the key via Help->About VisualGDB.

[codex653]

That does not appear to be the problem. I re-applied the license, got a “thank you for purchasing VisualGDB” message, restarted my computer, and still had the same issue.

On another note, I noticed while digging through the ProfileDriver_STM32_HAL.cpp file that the default Timer was set to 2. Coincidentally, that is the same timer I use in some of the code that I am trying to profile. Once I get this crash issue resolved I am going to switch the default Timer instance and see if that fixes it.

 

• This reply was modified 7 years ago by codex653.

[support]

Hi,

Thanks for confirming this. Looks like some internal VisualGDB component is throwing an exception and VisualGDB is not handling it properly. Please try this build:

http://sysprogs.com/files/tmp/VisualGDB-5.3.15.1915.msi

It should display a meaningful error message in this case.

[codex653]

I have reinstalled using the given file, yet no error message was displayed after the project properties window crashed.

[support]

OK, sorry about that. We have added another logging layer on top: http://sysprogs.com/files/tmp/VisualGDB-5.3.15.1916.msi (the link will become available in ~10 minutes)

Please open the View->Other Windows->VisualGDB Diagnostics Console window and enable logging before opening VisualGDB Project Properties.

[codex653]

The logging worked this time. I’ve attached the output of the console.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

OK, thanks for the log, that explains it. Looks like something is totally wrong with the temporary directory and this breaks the .Net framework. It is surprising it didn’t affect any other programs.

Please try deleting all files in the temporary directory and run chkdsk on the drive containing it.

[codex653]

By temporary directory do you mean my folder under C:\LocalTempProjects\embeddedUKFTesting\embeddedUKFTesting\VisualGDB\Debug\???  Or do you mean the Windows temp under C:\Windows\Temp, or maybe the VisualGDB temp folder in C:\Users\<myusername>\AppData\Local\VisualGDB?? I don’t want to accidentally delete the wrong thing.

[codex653]

Oh, and it definitely does affect other programs, mainly Visual Studio 2017. It keeps crashing. However this is only localized to my desktop. The exact same code and VS2017 setup works perfectly fine on my laptop.

[support]

Hi,

You can find out the temporary directory by running “cmd /k echo %tmp%”.

[codex653]

Got it. I ended up needing to do a repair/upgrade on VS, but now communication between VisualGDB and my Nucleo board is back up to speed. Unfortunately, I went to go test the Real-Time Watch window with the basic blinking LED program and still did not see any output. I have dynamic analysis set up and it is instructed to instrument all functions. I asked it to watch for when HAL_GPIO_WritePin gets called, but only get a blank screen, even after the function has been called multiple times already.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, we can walk you through diagnosing this. Please try setting a breakpoint in ReportFunctionRunTimeToRealtimeWatch() in the profiler framework.

Does the function get invoked? Does the rec.Address expression match the instrumented function address (the least significant bit will be 1 to signify the THUMB code)?

If yes, please try running a regular instrumenting profiler session and switch Live Profiling window to “Diagnostics”. It should show various statistical data (e.g. buffer utilization, samples/second, bytes received). Please attach a screenshot of the diagnostic data here (or simply list all the numbers) so that we can see what is going on.

[Author]

Posts