ESP32/Arduino problems

[pdpruyne@gmail.com]

Trying to try out VisualGdb.  Tired of arduino/platformio, looking to find a real dev environment for microcontroller software development, ESP32’s.

I am professional developer, longtime VisualStudio user, win11pro, vs2022.  Just downloaded and installed VisualGdb.   My immediate goal: get the debugger running.

Throughout this, when informed “You don’t have XXX installed, Install it?” I always picked Install, saw no errors reported, was allowed to proceed after each install step.  Anything un-mentioned below, was left at its supplied default.

————————————

Thought I’d start with something easy, this is what happens, tried a couple of rounds, same same:

1. picked “new arduino project”
2. (Project Type)    picked “create a new blinking led project”
3. (Arduino Device)   picked  “Nologo ESP32C3 Super Mini” ,  picked “Com 25”
4. (Debug Method – Debug using)
   1. from Usb Devices list, picked  “usb-ESP32S3/ESP32Cx built-in JTAG”
      1. (Debug Method – Test)  Fails with pop-up, “USB Composite Device does not appear to have WinUSB driver installed.”  That is correct.  Abandoned path, been down zadig ratholes before.
   2. from Debug Methods list, picked “OpenOCD”
      1. (Debug Method – Test)  Test Works!
5. Picked finish

Presto, looks good, a project, a source file.  I pick File/Save-All .

1. I notice banner “The currently selected Arduino platform produces binaries without debug information…”  I pick “Fix Build Settings”.  Momentary progress bars, then banner disappears.
2. I select Build, project builds ok.
3. I hunt around, find “Program FLASH Memory”, works fine, board starts blinking.  Sweet!
4. Feeling bold, I try F5
   1. VS swaps into its debugging colors, the various debugging sub-windows appear
   2. Get a big pop-up  “Debugging failed”
      1. GDB Session output :Your VisualGDB trial expires in 30 days!
         C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\esp-rv32\2302\bin\\riscv32-esp-elf-gdb –interpreter mi “C:/Usr/Iot/SysProgs/ApBl1/Output/Nologo_ESP32C3_Super_Mini/Debug/ApBl1.ino.elf”
         -gdb-version 
      2. Exception details: VisualGDB version: 6.0.105.5243
         —————— le3+l2 ——————
         le3+l2: GDB session exited prematurely. Please verify that the project is built, the selected GDB binary exists and the working directory is specified correctly. If GDB reports an internal error, try updating GDB or erasing the target’s FLASH memory using external tools.
         at le3.q()
         at p63.t_2()
         at VisualGDB.GDBDebugEngine.x1(pa3 a, j1 b)
         trace=[le3.q:5068, p63.t_2:39, VisualGDB.GDBDebugEngine.x1:69]
      3. openocd details: Info : Listening on port 6666 for tcl connections
         Info : Listening on port 51087 for telnet connections
         Info : esp_usb_jtag: serial (7C:2C:67:D1:7F:B8)
         Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
         Info : clock speed 3076 kHz
         Info : JTAG tap: esp32c3.cpu tap/device found: 0x00005c25 (mfg: 0x612 (Espressif Systems), part: 0x0005, ver: 0x0)
         Info : [esp32c3] datacount=2 progbufsize=16
         Info : [esp32c3] Examined RISC-V core; found 1 harts
         Info : [esp32c3] XLEN=32, misa=0x40101104
         Info : starting gdb server for esp32c3 on 51089
         Info : Listening on port 51089 for gdb connections
5. Tried putting the board into “boot mode”, holding boot while pressing reset, same result

I followed the example here: https://visualgdb.com/tutorials/arduino/esp32/

My steps differ only in how the jtag is connected.  I feel like the successful debug-method test result validates the choices I made.  The successful flash programming, and the board-doing-the-blink, also argue that things must be pretty-close.

How should I proceed?  What have I missed?

[support]

Hi,

Please try running the gdb executable shown in the message (C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\esp-rv32\2302\bin\\riscv32-esp-elf-gdb) manually. Arduino package vendors sometimes forget to ship required libraries with their packages, leading to this type of error.

[pdpruyne@gmail.com]

Hi.  Thanks for the quick response.

You got it first try.  That binary is indeed missing in that location.

Oddly, I find a binary (riscv32-esp-elf-gdb.exe) in 6 different paths.

The first in a directory structure installed by VisualGdb as part of the process of trying the steps in my post.

1. C:\SysGCC\esp32\tools\riscv32-esp-elf-gdb\14.2_20240403\riscv32-esp-elf-gdb\bin
2. C:\Usr\Espressif\tools\riscv32-esp-elf-gdb\14.2_20240403\riscv32-esp-elf-gdb\bin
3. C:\Users\pdp\.platformio\packages\tool-riscv32-esp-elf-gdb\bin
4. C:\Users\pdp\.platformio\packages\toolchain-riscv32-esp\bin
5. C:\Users\pdp\AppData\Local\Arduino15\packages\esp32\tools\riscv32-esp-elf-gdb\12.1_20231023\bin
6. C:\Usr\Ard15\packages\esp32\tools\riscv32-esp-elf-gdb\12.1_20231023\bin

1 & 2 are identical binaries.  5 & 6 are identical binaries.  3 is about the same size as the others, while 4 is 20-times larger.

I tried the quick&dirty trick of mklink to fix the issue, trying both symbolic and hard links.  No change.

I tried copying the binary in 5 to the specified directory, no change.

Tried running the copied executable in that directory with the –help option, got no output and a negative return value.  Tried the same thing with that same executable in its original dir, worked – got help output.

Concluded the executable is somehow chaining to other executables in it’s directory.  There are a whole set of versions there, from 3.3 to 3.12.  Copied ALL of them to the specified directory,.

Debugging “started” but output window pops the msg in red “Error erasing flash with vFlashErase packet”, followed by a warning message msg in yellow “Could not set a breakpoint on main. Step into a new instance will not work”

Deleted the copied set of executables.  Tried the single “large” binary in directory 4, same result, debugging starts and pops same error messages in output window about flash erase and breakpoint setting failures.

So, I conclude quick and dirty fixes are not enough.  Any suggestions on a “clean” fix?

 

[support]

Hi,

This is something for you to figure out. The Arduino package structure is not specific to VisualGDB and it’s not up to VisualGDB to fix it. You can ask on the ESP32 forum – there are likely others that encountered the same problem.

[pdpruyne@gmail.com]

Ok, I get it.  VisualGdb has requirements and they need to be met.

I have questions then.

I have previously installed the Arduino toolchain, and likewise for PlatformIO.   I gather VisualGdb locates a likely toolchain for it’s “Arduino” needs.

How is this done?   Is it looking in specific locations?   Is there a list of specific targets I should insure are present to avoid a recurrence ?

You speak of “Arduino package vendors”.  I guess I’m asking from which source should I be looking, and what version?  Is your reference vendor not github/arduino?

I also have installed the Esspressif-IDF toolchain and Eclipse based IDE.

During VisualGdb installation a new toolchain was put into \SysGcc.   This toolchain is identical to the Esspresif-IDF toolchain.

Do I need to retain the Esspressif-IDF/Eclipse-IDE installations to use the Esspressif project type added by VisualGdb?

If I acquire a full featured Arduino toolchain, how do I make VisualGdb aware of it?  If that is a re-install of VisualGdb, how does that affect the trial status?

 

[support]

The Arduino projects are completely separate from the regular ESP-IDF projects. You can read more about them here. The ESP-IDF projects are described here.

There is no need to reinstall VisualGDB – it checks for installed packages every time you start Visual Studio. Reinstalling it does not affect the trial status.

[pdpruyne@gmail.com]

In reading the link you provided about Arduino projects, I find this statement:

“The Arduino projects are built directly using our fork of the official Arduino Builder tool. The tool automatically manages various build parameters same way it does with the regular Arduino IDE. This ensures that the output of VisualGDB Arduino projects is equivalent to the files produced by the Arduino IDE.”

The failing command line is pointing into the toolchain installed by ArduinoIDE.  That seems in conflict with the statement above about a using a fork of the Arduino Builder Tool.  Can you explain?

[Aloysius_Pendergast]

Don’t waste your time. I recently had the same problem and sought help here. I think the guys here can’t solve the problem or aren’t interested in it. Unfortunately. Because VisualGDB has the potential to become the best IDE for ESP. It is based on a good foundation: Visual Studio. That’s much better than VIC or Eclipse. Everything works fine with the IDF framework. And six months ago, everything also worked with the Arduino framework under VisualGDB. Currently, it doesn’t. They blame the Arduino framework. However, they load the corresponding frameworks themselves, which then become incompatible with the other components. I wouldn’t buy the software until they fix it. As an alternative, I am currently using Visual Micro. Also not perfect, but it works.

• This reply was modified 1 month, 2 weeks ago by Aloysius_Pendergast.

[support]

The trouble with the Arduino system is that every vendor (original AVR Arduino, ESP32, STM32, etc) ships their own packages. Often, new package versions fix some bugs from the previous versions and introduce some new bugs. Each of them has their own bug tracker, their own Github repository and their own community. So any work we put into resolving these issues will get completely obsoleted when the next package version comes out. Except, then we would get more requests for help, more issues to fix, and it would quickly snowball to the point where none of the work we do actually improves VisualGDB in the long run, and is quickly obsoleted by another update. We tried it before, we really did, and it’s just not viable, sorry.

What we can reliably offer is  convenient GUI and deep integration with VS. You can configure existing package paths and not download anything new. You can choose the framework versions to download. You can decide whether to upgrade or not. You can revert to the old version if the new one is not working. We provide the GUI for all of that, but we cannot take over the maintenance work done by the package vendors. If the latest ESP32 Arduino package has broken debugging on Windows due to some missing libraries, it will remain broken until Espressif releases a fix for it.

As for our builder fork, the only modifications we introduced is accurate dumping of all GCC command lines, so VisualGDB can offer best-in-class IntelliSense that is way more accurate than any other IDE that does not have access to the underlying command lines.

As for the other IDEs, if you can confirm that the same functionality (e.g. debugging) works with another IDE on the same machine with the same versions of all libraries/packages, etc., we can help you configure VisualGDB to match that setup. But we will ask you to narrow it down to specific command lines on your own.

[Aloysius_Pendergast]

 

I understand your arguments. But I think you have tested your system with the Arduino framework at some point, in a working version. So, you should know which version of the Arduino framework is compatible with the other stuff of OpenOCD and GDB.

You advertise with: VisualGDB recognizes the Arduino, ESP-IDF, Mbed, NRFConnect……..

When I load the Arduino framework as a user in VisualGDB for the first time and  when creating an Arduino project, it currently downloads automatically  a non-functional Arduino framework. But why? As I mention you should know which one works. So why not simply load compatible components, as PlatformIO or VisualMicro can do?

[support]

When I load the Arduino framework as a user in VisualGDB for the first time and when creating an Arduino project, it currently downloads automatically a non-functional Arduino framework. But why?

Because Espressif published it as a stable package ready to download. If you install the Arduino IDE and create your first project on the same day as with VisualGDB, it will download exactly the same versions of all packages.

As I mention you should know which one works.

We do that with regular ESP-IDF. A couple of times a year Espressif releases a new toolchain and a new major ESP-IDF update. We quickly test them together, bundle them as a package and release it as a single tested download.

Arduino is much more decentralized with thousands of libraries, cores and packages, so every single day something new gets released somewhere. It’s a great way to quickly put together some proof-of-concept code out of pieces made by others, but it will always involve some troubleshooting and dealing with broken incompatibilities due to the sheer decentralized nature of it. And based on the feedback we get, people often use it for all kids of exotic devices, forks and drivers we never heard about, so limiting it to a handful of verified packages will simply kill most of the use cases.

If you are not comfortable doing it, please use another platform. The STM32 SDKs are rock solid and are additionally tested on our side before each update.

[Aloysius_Pendergast]

We do that with regular ESP-IDF. A couple of times a year Espressif releases a new toolchain and a new major ESP-IDF update. We quickly test them together, bundle them as a package and release it as a single tested download.

Then please inform the buyers of your software which version of VisualGDB is compatible with which Arduino package.

Arduino is much more decentralized with thousands of libraries, cores and packages, so every single day something new gets released somewhere. It’s a great way to quickly put together some proof-of-concept code out of pieces made by others, but it will always involve some troubleshooting and dealing with broken incompatibilities due to the sheer decentralized nature of it. And based on the feedback we get, people often use it for all kids of exotic devices, forks and drivers we never heard about, so limiting it to a handful of verified packages will simply kill most of the use cases.

If this is so complicated or impossible, then please inform your customers that it probably won’t work with Arduino and VisualGDB before they spend money on the software.
I used the trial period of the software, during which everything worked. Then I bought the software because everything worked well, and then it suddenly stopped working.

 

If you are not comfortable doing it, please use another platform. The STM32 SDKs are rock solid and are additionally tested on our side before each update.

Tat sounds like a good customer service. And that is what I currentlly doing and what I recomend to the other customer here. For STM32, I use Keil µVision or CubeIDE. There is no reason to use anything else. Debugging and simulation are very good with this IDE’S.

[Author]

Posts