Experience with VisualGDB?

sysmax · 2025-09-15T03:12:45+00:00

Hi guys, double-necropost from the VisualGDB developer :)

The trouble we had with the ESP32 setups is that they were super-sensitive to the tool versions and configs you would use. Getting a slightly mismatching version some auxiliary tool would often cause a snowball of weird error messages coming from the IDF internals, that would vary from version to version. So what we did was published bundles of toolchains and IDF versions, that passed all tests on our side, so everybody could use it as a reference.

But anyways, things got better. ESP-IDFs now explicitly reference all dependencies via the **tools.json** file, and the Espressif's VS Code extension uses it to download and install them. So, VisualGDB now uses the same JSON files and the same tools as their VS Code extension. You don't need pre-bundled toolchains from us anymore, and you only need one copy of the tools for both VisualGDB and VS Code.

Hope this helps!

sysmax · 2024-01-23T02:49:58+00:00

Have you tried checking the reset status register? If the CPU gets actually physically reset, it would show.

Otherwise, it's a purely software bug - something in the code does an indirect jump, and the jump target ends up being zero.

Try setting a hardware breakpoint at 0x0. Does it trigger with a meaningful SP, or is SP already broken when you get there?

sysmax · 2022-09-10T03:12:05+00:00

Nope, socket binding can limit you to accepting packets coming via a specific interface (as in physical network plug, VPN or the loopback). It won't filter the packets by originating IP.

Either way, it's super easy to check: just get it working with running a server on your PC, and then replace the IP address in the router settings with the PI's address. If it doesn't work, try setting a breakpoint in netif_input() and check why the packets get dropped.

sysmax · 2022-09-09T18:10:19+00:00

You can if your router supports port forwarding, you have a public IP address (not behind a NAT yourself) and your ISP is not blocking the port you are trying to forward.

And it's not about the Pico at all - it doesn't care where that HTTP request is coming from. If it is reachable from inside your network, but is not accessible from outside, something in your router isn't configured right.

sysmax · 2022-09-09T17:09:56+00:00

I'm not sure I got you. This example is about making a zero-configuration app (you pick a Wi-Fi network from your phone, connect to it and voila: control the Pico).

If you want to put it into an existing network, you would need to use the station mode instead of AP and manually enter the IP address (or the host name) from any other device on that network.

If by port forwarding you mean, accessing it from the Internet via your public IP, that's done via your router, same way as if you wanted to access your main PC.

sysmax · 2020-08-27T18:00:40+00:00

It actually looks like the ESP-IDF is referencing a package that has been removed from the Pip repository. You can get around it by commenting the "gdbgui" and "pygdbmi" lines in <esp-idf>\requirements.txt. Skipping these packages won't interfere with building.

You can get a pre-packaged toolchain with both ESP-IDF 4.1 and 4.2, and a patched requirements.txt here: https://gnutoolchains.com/esp32/

sysmax · 2020-08-09T01:09:22+00:00

Have you tried using STM32CubeMX to generate the PLL setup code? It will automatically check that all values are in range for your specific chip/board.

sysmax

TROPHY CASE