[support]

Hi,

You can set per-user variables and simply reference them in the path mappings.

[support]

Hi,

The problem is that this behavior is defined inside the gdb itself and the only way to override it would be via modifying the gdb sources. As there are many different platforms where gdb runs, maintaining such a modified version would be unsustainable.

VisualGDB does not show getters by design – to avoid accidentally invoking some function that may crash your program. If you want to get more usable display of your variables and fields, you can create .natvis files defining how to extract meaningful information from complex objects.

[support]

Hi,

Thanks for the video. The problem might be related to the one of the changes you made. To double-check that please try running exactly the code we provided, without disabling the watchdog and with exactly the same period.

If you can confirm that it does not work, the problem is in the hardware. If it starts working after removing watchdog-related code, the problem is related to the watchdog.

Regarding os_printf(), the gdb stub does support that. VisualGDB currently displays the output from the stub in the GDB Session window together with the other gdb output (you need to select “All GDB interaction”). We will support displaying it separately in the next major release of VisualGDB.

[support]

Hi,

This comes from the gdb’s implementation of running functions in Watch expressions. It runs them ‘as is’ and does not check for things like null pointers.

Evaluating functions in-place is a powerful debugging feature, but it needs to be used carefully as there is no 100% safe way to run arbitrary functions in native code without potentially crashing the program.

[support]

Hi,

Normally VisualGDB should be able to parse the GCC output and show it in the Errors window. Are you using a cross-compiler or compiling directly on the Linux machine?

[support]

The link shows “the video is private”. Did you manage to get the code we sent working without any modifications?

[support]

Hi,

Perhaps something is wrong with the power supply of your board and it’s constantly resetting itself? We have tried the following project with the gdbstub and were able to step over a breakpoint on the s_Tick++ line:

static os_timer_t s_Timer;
int s_Tick = 0;

void TimerFunction(void *arg)
{
    s_Tick++;
    asm("nop");
}

int user_init()
{
#ifdef ESP8266_GDBSTUB
    gdbstub_init();
#endif
    gpio_init();

    os_timer_setfn(&s_Timer, TimerFunction, NULL);
    os_timer_arm(&s_Timer, 300, 1);
    
    return 0;
}

Can you verify that you get the same behavior with this reduced program? If yes, please try getting an Olimex board. The ESP8266 chips are not very reliable, so it could easily be a strange hardware problem.

[support]

Hi,

Yes, that’s the easiest workaround. VisualGDB indeed assumes that same host name means the same remote machine and adding extra entries to hosts should to the trick.

[support]

Hi,

Please try the following:

1. Change the firmware to turn on the LED, disable interrupts and wait indefinitely
2. Try programming the firmware using JTAG. If it does not start, unplug the board and plug it back. Does the LED actually turn on after you restart the board?

[support]

Thanks for the suggestion. We are actually considering similar functionality (auto-import of sources from CMake files), but it’s hard to say currently what extent of it will be included in v5.2 as there are still some unresolved things left.

[support]

Hi,

It’s hard to suggest anything without seeing the outcome of the tests suggested above. We have ordered a bunch of ESP-03s and will make a tutorial once they arrive.

If you need a trial extension, simply use the contact form on our website and mention this thread and we will extend your trial.

[support]

OK, first of all, we did test all the projects on the Olimex board, so it is probably some small configuration issue with ESP-03. In order to resolve it, you need to localize the problem. It can be in one of the following places:

• FLASH programming never happens
• FLASH programming succeeds, but starting the program fails
• The built images are wrong
• The program fails to start with JTAG attached

To figure this out, please try the following:

1. Change the firmware to turn on the LED, disable interrupts and wait indefinitely
2. Try programming the firmware. If it does not start, unplug the board and plug it back. Does the LED turn on?
3. If yes, try debugging it with no FLASH programming. Does this help? If yes, try changing the reset mode in VisualGDB Project Properties.
4. If the programming does not turn on the LED, try programming the same .bin images (not the .ELF file) using esptool. Does this work? If yes, something breaks programming and the full GDB log might provide answers.

If you encounter any difficulties at any point, please feel free to share the details and we will try to help you.

[support]

Hi,

It is fully supported. Simply follow this tutorial: http://visualgdb.com/tutorials/linux/cmake/import/

[support]

Hi,

Thanks for the detailed video. We have added a new option to Tools->Options->VisualGDB that controls the behavior when the toolchain test is canceled. It will now ask whether you want to save the settings by default, but you can also change to save always or never.

You can download a build with this feature here: VisualGDB-5.1.4.676.msi

[support]

Hi,

Please try experimenting with the FLASH type, speed and size settings. The default ones are valid for the Olimex ESP8266 board and different settings may be required for ESP-03.

[Author]

Posts