[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.

[support]

Hi,

Raw Terminal is only available in the Custom and Ultimate editions. If you want to upgrade, please contact our sales so that they can give you a quote.

[support]

Hi,

It looks like you are trying to link the Crypto++ library compiled for Win32 with the VisualGDB project for Edison. As the library is incomptaible with the Edison toolchain, it simply ignores it.

Please build the library using the same cross-toolchain you use for your project and link to the cross-compiled version of the library instead.

[support]

Hi,

VisualGDB navigation bar also supports the ‘Go’ button. It also parses the preprocessor definitions and allows going to either the definition itself, or one of the functions/types contained in the definition:

[support]

Hi,

Yes, our .pro file parser is very basic and does not support conditionals. As a workaround, you can disable deployment, add custom deployment actions specifying your target name and explicitly specify the modified target name as the program to debug.

[support]

Hi,

The “regenerate MCU files” button is only available starting from the Custom edition.

If you are using the Embedded or Linux edition, you can simply change something on the Makefile Settings page (e.g. add a space to CFLAGS and delete it) and press “Apply”.

[support]

Hi,

The main project needs to reference the library projects. Then VisualGDB will automatically grab the path mappings from them when debugging the main project.

Alternatively you can specify the mappings for the library sources manually via VisualGDB Project Properties -> Path Mapping.

[support]

Hi,

We did test that (made the temporary directory unwritable, then changed some settings, clicked ‘apply’ and then ‘cancel’ when VisualGDB complained about the directory). The settings were saved properly.

Perhaps the problem you are observing only affects some specific settings? Could you provide a more detailed description:

• What setting are you modifying
• When exactly do you cancel the test
• What do you expect to be changed
• How do you verify that it’s not changed

This should help us reproduce the problem on our side.

[support]

Hi,

The live variables are normally stored in the .vgdbsettings.user files. Perhaps your file is not writable and VisualGDB cannot update it properly? Either way, you can delete the file to reset all per-user settings like live variables.

[Author]

Posts