Forum Replies Created
-
Posts
-
Hi,
This is a known issue. The automation interfaces used by Visual Studio do not support specifying paths like $(LOCALAPPDATA), so VisualGDB has to hardcode the path in the project file. Normally if you open the file on a different machine with a different user name, VisualGDB should automatically adjust the references (this may sometimes not work if the project and the $(LOCALAPPDATA) directory are located under the same drive letter).
Hi,
We have released an updated OpenOCD build. You can install it via Tools->Manage VisualGDB Packages.
Hi,
Normally VisualGDB should use the $(LOCALAPPDATA) syntax in the Makefile. If not, can you confirm that you are using the latest VisualGDB 5.2r9?
Hi,
Yes, but only if you are using Visual Studio to build the projects and both projects are included in the .sln file and selected for build.
BTW, if you are planning to do remote builds, the VisualGDB MSBuild backend actually generates temporary Makefiles (this reduces latency compared to running each compiler instance separately from the Windows side), so you can copy them manually to your Linux target and build them without VisualGDB as well. This only applies for remotely build projects though.
Hi,
The .bin file produced by MSBuild won’t be helpful, however you can use the esptool.py tool to program the ELF file (usually same name as the .bin file and no extension). To get the exact esptool.py arguments for programming the file, please try programming any project built with the command-line ESP-IDF tools and check the build/programming log.
Hi,
No problem, we will make an experimental build of OpenOCD based on the latest upstream sources and will post a link here in the next 24 hours.
Hi,
We are currently in the last stages of the new CMake project subsystem and are experimenting with accessing the Linux filesystem directly, so you can open the remote projects without keeping a separate Windows checkout of the sources. We will most likely release a public preview next week.
Hi,
Yes, you can use the regular project dependencies/references window in Visual Studio.
BTW, is there any special reason why you cannot use MSBuild? It provides most of the functionality that GNU Make does.
Hi,
Sorry, this is not supported for GNU Make. You can try hacking the Makefile at your own risk to achieve that, but we generally recommend switching to MSBuild as it provides a straight-forward way for defining per-file arguments.
Hi,
We usually update the BSPs quarterly, so the next update will be released within the next 1-2 months.
Hi,
Thanks for confirming this, we will note down that TUMPA is compatible with ESP32.
Regarding single-core mode, you can actually try editing the <SysGCC>\esp32\esp32-bsp\OpenOCD\share\openocd\scripts\target\esp32.cfg file (uncomment the set ESP32_ONLYCPU 1 line), although we have not fully tested this mode and it may result in strange bugs.
Hi,
Please ensure you are using the MSBuild subsystem (not GNU Make). Then you can use the regular VS properties for individual files or groups of files to edit various settings.
Hi,
This happens because once you hit ‘Step over’ or ‘Step in’, an interrupt occurs and OpenOCD is trying to step over the interrupt handler to get back to your code.
You could try disabling this behavior by temporary setting the ‘$PRIMASK’ register to 1 via the Watch window and then stepping. However this will delay the interrupt handler until you set PRIMASK back to 0, so some buffer overruns/underruns may occur.
Hi,
This could be caused by the ESP32 configuration, or by incompatibility with TUMPA (we do not officially support it and have not heard of anyone successfully using it). The easiest way to get it to work would be to get the same hardware as shown in our tutorials and ensure your wiring 100% matches the one shown there. Once you get it to work, it would be easier to switch the debug adapter (or the ESP32 board) and quickly pinpoint what exactly is causing the problem.
