Sysprogs forums › Forums › VisualGDB › After updating to 6.0r3 Arduino ESP32 toolchain debuging does not work anymore
- This topic has 3 replies, 2 voices, and was last updated 2 months, 2 weeks ago by support.
-
AuthorPosts
-
September 28, 2024 at 13:07 #36034Aloysius_PendergastParticipant
After updating VisualGDB to 6.0r3 everything works fine with debugging. I use the ESP Prog for debugging. But for Arduino projects debugging is not possible. Before updating to 6.0r3 also Arduino projects debugging worked without any problems.
Now, if I use the JTAG for flash and debug I get a flash error. See attachment. If I use the Arduino tolls for flashing I get a GDB Session Error.
Thanks for help!
Attachments:
You must be logged in to view attached files.September 30, 2024 at 13:52 #36037supportKeymasterHi,
It looks like an issue between OpenOCD and a particular board. We do not know what is causing it – both the ESP32 OpenOCD port and the board are provided by Espressif.
Our best advice would be to first get it working via command line (i.e. being able to program FLASH on the same board with OpenOCD manually). When this works, we can help you configure VisualGDB to match the OpenOCD command line that worked.
October 6, 2024 at 12:53 #36051Aloysius_PendergastParticipantSorry but I’m sure this has nothing to do with the board. A couple of weeks ago everything works fine with the same hardware. Other HW that worked before is also affected by this error.
I have paid for a software that contains an ‘Arduino Project Wizard’. Which suddenly stopped to work as before. Also on another PC with a clean install. The error must be in your software. I think I could expect more from a paid support than always shifting the problem to other components. You are the experts who sell software that should relieve releave customers of this kind of trouble.
LW
October 6, 2024 at 13:30 #36052supportKeymasterHi,
The problem you are describing involves 6 different components:
- The actual board
- The firmware running on the board
- The JTAG debugger
- The OpenOCD tool that talks to the debugger
- The Arduino package that contains rules for building the software
- VisualGDB used as a GUI on top of this
The role of VisualGDB here is to provide convenient GUI for automating common development tasks. E.g. the graphical editor for the KConfigs with convenient search and grouping, automatic editing of CMake files, etc. The underlying components come directly from hardware vendors, Arduino community, etc. They sometimes have bugs, and sometimes have incompatibilities between different versions. We do not charge you anything for using them. We do not require that you buy a JTAG debugger from us, a specific board from us, use only libraries approved by us, etc. Hence, if some of these external components don’t work as intended, it’s generally up to you to figure it out.
We try to be fair: if you can get debugging to work with the same board using the same Arduino package outside VisualGDB, we can help you find VisualGDB settings that will allow replicating the working setup. If it’s not working outside VisualGDB, you would need to find the most similar setup that works (e.g. another board), and iteratively compare the two setups until you find the root cause of the differences. This could be frustrating and time-consuming, but this is the way to go if you encounter problem spanning across many different components.
As for being experts, if we wanted to fully solve this problem, we would need to get the same board, same versions of the packages, reproduce the problem, and then try other combinations of Arduino packages, toolchains, ESP-IDF versions, etc., narrowing down the combination that causes trouble. It would take multiple hours (+ purchasing extra board) and would not result in any improvements to VisualGDB. The conclusion would be that a particular version of ESP-IDF doesn’t work well with a particular version of some library when using some particular combination of settings. And even that finding would be obsoleted when Espressif released another version of their package. If we offered this as a part of our regular support, we would have to raise the product prices several times to the point where very few users would be interested in it. So instead, we limit the included support to VisualGDB-specific issues (we have detailed page explaining it) and can gladly fix virtually anything else at our hourly consulting rate.
-
AuthorPosts
- You must be logged in to reply to this topic.