esp32 jtag clock setting stuck at 3000kHz

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

Tagged: 

Log In Register Lost Password
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • March 24, 2019 at 12:02 #24451
    John Devereux
    Participant

    Hi

    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

    Thanks

    John

    March 25, 2019 at 09:10 #24452
    John Devereux
    Participant

    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.

    Thanks

    John

     

    March 26, 2019 at 01:15 #24460
    support
    Keymaster

    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.

    March 26, 2019 at 09:09 #24462
    John Devereux
    Participant

    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.

    CMake Error: The current CMakeCache.txt directory C:/Users/jd/source/repos/EmbeddedProject2/VisualGDB/Debug/CMakeCache.txt is different than the directory c:/SysGCC/esp32/esp-idf/v3.2/examples/get-started/hello_world/VisualGDB/Debug where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
Exception reported by CMake server: Failed to activate protocol version: "CMAKE_HOME_DIRECTORY" is set but incompatible with configured source directory value.
em+i: Exception reported by CMake server: Failed to activate protocol version: "CMAKE_HOME_DIRECTORY" is set but incompatible with configured source directory value.
at em.p[_InType,_OutType](_InType a)
at u31.e1(String a, String d, String c, String b)
at u31.l1_2(Hello a)
at em.d1()
Shutting down CMake project for C:\Users\jd\source\repos\EmbeddedProject2\EmbeddedProject2.vgdbproj...

    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

    File/new/project

    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.

     

     

    Attachments:
    You must be logged in to view attached files.
    March 26, 2019 at 18:08 #24473
    support
    Keymaster

    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.

    March 27, 2019 at 15:59 #24475
    John Devereux
    Participant

    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

    John

     

    March 27, 2019 at 17:15 #24478
    support
    Keymaster

    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.

  • Author
    Posts
Log In Register Lost Password
Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.