esp32 jtag clock setting stuck at 3000kHz

Sysprogs forums Forums VisualGDB esp32 jtag clock setting stuck at 3000kHz


This topic contains 6 replies, has 2 voices, and was last updated by  support 3 years, 10 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #24451

    John Devereux


    For Segger JLink the JTAG clock project setting is stuck at 3000kHz. I can change it by editing the .vgdbproj file directly, provided I don’t try to change it again in the GUI.

    I am using VisualGDB 5.4R3, ESP-IDF 3.2, VS201916.0.0.RC.2




    John Devereux

    Ah it works OK if I use the “Test” button before applying the setting ๐Ÿ™‚ So I guess it is working as intended.

    You could perhaps grey out the Apply & OK buttons until this is done.






    Sorry, we have tried reproducing this on a basic ESP32 project (opened VisualGDB Project Properties, changed the frequency to 4000, pressed OK) and it got applied correctly.

    Most likely the issue is triggered by some specific combination of settings in your project. If you could share the screenshots of each related step (i.e. project properties before/after and also the Solution Explorer so that we could see the project type) and let us know what exactly you are changing and in what order, we should be able to fix this.


    John Devereux

    OK, to be clear, it works fine provided I use the “test” button before closing the dialog. So I do not have a problem any more.

    But it is still true that if I just change the setting and press OK, the old value is used.

    I reproduced the same problem with a default esp32 CMake project using the hello world example.

    Then I repeated this so I could get some screenshots for you. This time the created project failed to load with errors about cmake cache.

    So I reloaded the project and now I am unable to reproduce the problem!

    I went back to the original project. Sometimes it accepts the change without testing, sometimes it does not. Is it dependent on how long I wait before checking? There is background project reconfiguration happening in the output window.

    The projects are started with a workflow like


    Choose ESP32/ESP8266 IDF/ADF project wizard … create

    Create a new CMake project based on sample

    ESp32 toolchain, v3.2 SDK

    get-started/hellow world

    Choose the detected segger jlink, accept defaults


    Go into project debug settings, change 3000kHz to 4000kHz, press OK.



    You must be logged in to view attached files.


    Thanks for the update. Theย CMAKE_HOME_DIRECTORY error would happen if you had previously built the sample project in-place with different CMake settings (normally, VisualGDB would not do it when using the “new project based on sample” mode in the wizard). Either way, doing a rebuild should clear out any cached files.

    VisualGDB indeed does some background work when you open the Debug Settings page of VisualGDB Project Properties – it scans for the connected USB JTAG probes and ensures you can select a different one.

    We have tried using different delays (anywhere between 1 and 10 seconds), but unfortunately still could not reproduce it. If the problem happens again, please try creating a video showing:

    • The entire VS window (specifically, the Output -> Advanced VisualGDB Project pane) so that we could see the status of the background project load.
    • The process of opening VisualGDB Project Properties, making the change, closing the window and opening it again to get the incorrect value.

    You do not need to record the creating of the project, as the settings picked in the wizard that might affect the device selection are clearly visible from the Debug Settings page.


    John Devereux

    Now I am finding it harder to reproduce the problem, and never when I am recording video! I am starting to think the overhead of video recording fixes it ๐Ÿ™‚

    It still happens occasionally but it is not a problem for me now, if I manage to get it repeatable again I will f0llow up.

    Thanks for your help





    No problem. It is most likely caused by some sort of a race condition, so it’s hard to narrow it down without being able to reproduce it reliably, or at least having some clues from the video.

    Either way, if you encounter the problem again (or if anyone else encounters it), please feel free to share a video and we will be happy to look deeper into this.

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

You must be logged in to reply to this topic.