CPU frequency missing in project configuration

Sysprogs forums Forums VisualGDB CPU frequency missing in project configuration

This topic contains 10 replies, has 4 voices, and was last updated by  support 3 weeks ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #33697


    I have successfully compiled several ESP8266 and ESP32 projects using VisualGDB.
    The original setup included version 4.x ESP tools.
    I have updated it to version 5.0 and noticed that all of my ESP32 projects are now compiling with CPU speed set to 160 MHz.
    I have looked high and low throughout the project settings and the …CPU_SPEED… is just not there.
    I inspected the sdkconfig and sdkconfig.default file in the ESP32 project directory and the settings are there:

    # CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_240 is not set

    But no way to select/set it…
    So I am not sure what is going on.
    I am not sure if there are other parameters missing in the project settings, but this one was one I noticed.
    Attached image is showing a fragment of both ESP8266 and ESP32 project settings pages (Missing CPU Frequency setting in ESP32).







    These settings come directly from the ESP-IDF framework (you can verify this by running the menuconfig command manually as described here). They can differ between different devices and different ESP-IDF versions. If you need help locating a specific option, the best way would be to search the ESP-IDF documentation, ask on the Espressif forum, or look for ESP-IDF examples that could be using that setting.




    I think you totally missed my point:

    I am aware how to set the parameters. I am not asking: How? I am letting you know, that you are missing some configuration parameters in project settings that Your software is collecting from the user.

    Let’s walk through a simplest example and see if we arrive at the same point (I am using the latest ESP-IDF v5.0) and the target is ESP32 chip:

    1. Open VS and using VisualGDB create BLINK example from “get-started” folder. Let  it finish and then…
    2. Using VS or any other text editor, open “sdkconfig” file in the project root directory
    3. Scroll down to line number 707: You should find settings for the CPU frequency: Options are: 80, 160 and 240 MHz (or search for “CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ”)
    4. Go back to VS and open “VisualGDB Project Properties”
    5. Based on that “sdkconfig” file, the VisualGDB creates a dialog to collect new project settings from the user (I assume).
    6. Where is the CPU_Frequency setting in “VisualGDB Project Properties”? I “Filter” for: CPU, Freq., MHz and even scrolled through the whole configuration: It’s not there.

    Relevant fragment of my sdkconfig file:

    You are missing at least 1 parameter for the project settings. And I would have never found it, if it was not for the fact that the Espressif default frequency is 160MHz and I want all my chips running at 240MHz. It looks to me, like you are missing some parameters from “ESPxxx specific” section.

    Here is “platform.io” configuration for the same ESP32 chip (same example):

    I did not checked all, but in addition to CPU frequency, you are missing “Brownout Detection”, “Brownout Voltage”,…


    PS: VS2015 on W7 32GB / 4TB



    The sdkconfig file contains the values of the parameters, but not their descriptions. The actual descriptions are stored in the KConfig files scattered across the ESP-IDF folder. VisualGDB parses them, combines the result in a convenient searchable tree, fills it with values from sdkconfig and displays it on the first page of VisualGDB Project Properties.

    Different ESP-IDF versions can have slightly different setting layouts (e.g. a the same setting could be called differently) and VisualGDB Project Properties would reflect it.

    We can double-check the CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ setting on ESP-IDF 5 if you could share a screenshot of your Help->About VisualGDB window to make sure we are looking at the same thing.




    Here it is (my  Help->About VisualGDB).

    Thx for looking into it.




    No problem,we have rechecked it. Indeed, Espressif has moved the definition of the CPU-specific settings in a way that VisualGDB couldn’t properly parse. We have updated VisualGDB to handle it properly: VisualGDB-



    Thank you.





    there is a same bug that in “ESP PSRAM”

    in visual gdb:


    and esp menuconfig:


    please fix it 🙂



    Please make sure you use an unmodified version of the VisualGDB installer with a valid license.



    I hit this problem too, on (Help → About VisualGDB) version 5.6R9 (build 4769) , purchased on 11 Feb this year. I was pleased to find there is already solution.

    However, I’m not sure how I’m supposed to find the latest version of VisualGDB in general?

    • Visual Studio doesn’t report any updates are available for this add-in,
    • Your e-commerce emails don’t provide any download links,
    • Your download page supplies version, the same version used by the OP, with this problem
    • This page has a direct link to version, though that doesn’t seem to be the latest version either as builds 4808, 4809, and perhaps others, also are available.

    Would you mind clarifying how we are supposed to learn about updates and where the latest version, now and in the future, can be obtained please?

    Ah, it looks like a number larger than the latest build might return the latest build. Is this the recommended approach?




    Sorry for the confusion, we will explain it below.

    The latest stable VisualGDB version, that has fully passed all tests is 5.6r9 (build 4777).

    The build 4807 is from our development branch (the latest build there is VisualGDB- This branch is updated very regularly, contains recently added features and fixes requested by our users, but has not fully passed all tests and might be less reliable than the official release.

    We are currently finishing our work on the new tracing engine, that will first be published in the upcoming VisualKernel release, and will then make its way into VisualGDB 6.0 Beta 1. This Beta will include all the fixes from the development branch, including the one you mentioned. Until then, we would advise using the development build.

    Substituting the build number would indeed get you the latest development build, however it normally shouldn’t be necessary, as the latest beta that will appear on the download page will include most of the recently added fixes.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.