Instrumentation Profiler Issue

Sysprogs forums Forums VisualGDB Instrumentation Profiler Issue

Tagged: 

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #30566
    v_krishnan
    Participant

    I’m using VisualGDB for an embedded project, with STM32F4 device and using the StdPeriph library (not HAL).

    My project compiles successfully, and I’m able to debug the same without issues.

    I then setup the instrumentation profiler to analyze the performance of various functions of my code.

    Now, in my main(), I’ve few functions in the very beginning to setup the device pins, etc. After this I call the InitializeInstrumentingProfiler function to setup the profiler. Now when I debug through the “Analyze” option, I land up in the hardfault handler as soon as the first function to setup the device is called, i.e., even before InitializeInstrumentingProfiler is called. If I debug it normally, i.e., without Analyze, then I don’t face any issue.

    I’ve even tried moving the InitializeInstrumentingProfiler  as the first call inside main(), but the issue remains the same.

    On further debugging, I find that crash happens inside the SYSPROGS_THUMB_HOOK_PROLOGUE sequence which is executed as part of the profiler-stub on entry of each function.

    Any ideas to identify and resolve this problem?

    #30601
    support
    Keymaster

    Thanks for renewing your support. Instrumenting the code for profiling could result in crashes if the original code was corrupting the memory, had possible race conditions or other implicit dependencies.

    In order to troubleshoot it, please try the following:

    1. Instead of using the Analyze command, try enabling real-time watch in VisualGDB Project Properties -> Dynamic Analysis, but don’t create any watches yet. Does this result in a crash?
    2. If yes, please try changing the instrumentation settings on the Dynamic Analysis page to only instrument one or two functions (e.g. the one controlling the LED). Does the code still crash?
    3. If instrumenting only one function stops the crashing, the problem is caused by instrumenting some of the low-level system functions. Please try excluding all low-level functions from being instrumented to see if it solves the problem.
    4. If instrumenting only one function still causes crashing, please try reproducing the problem on a clean project created from scratch for the same device. Once you get it reproduced, please share the repro project with us and we will investigate it further.
Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.