Forum Replies Created
-
Posts
-
Sorry, unfortunately there is no easy way to do this, as the Arduino build logic is handled by the Arduino builder and not directly by VisualGDB.
You should be able to extract the gcc command lines by parsing the VisualGDBCache\<Target>\CodeModel.json file, extracting the gcc arguments from there and running it manually with the -S option instead of -c, although that would require some scripting on your side.
Hi,
Looks like you forgot to specify the “–interpreter mi” argument in the gdb command line. This argument is required in order to enable the “machine interface” – a special mode where gdb produces machine-readable replies to commands instead of the regular text replies.
VisualGDB would normally handle this automatically for the regular debug configurations, however using the fully custom mode shown on the screenshot requires specifying it manually.
Hi,
It looks like the project has some leftovers from the previous BSP version, or previous configuration. Please try rebuilding it via Build->Rebuild All.
According to our records, the recent VisualGDB updates did not change anything that could be causing this issue.
You have also mentioned several different issues in this thread that would occur under different setups, so it is hard to understand what is going on based on your description.
Please try installing the toolchain from scratch and check whether creating a new Qt5-based project for the target works.
Hi,
According to our records, your support period has expired. In order to continue receiving technical support, please renew your key here. If you have purchased a different key with another email address, please let us know or update your forum profile.
It looks like your toolchain is not compatible with your target. As a workaround, please try building the code directly on the target.
Hi,
Sorry, but the only way to tell what is going on is to check the View->Output window as suggested by the second error message on the screenshot. It will show the detailed build log that should point to a specific part of the build that failed.
Thanks for the details and sorry for the confusion. We have rechecked everything and found the root cause of the problem.
When the main application is rebuilt, the “clean” stage of the build deletes the built files from the project output directory, following the regular Visual Studio logic. This also results in deletion of the .bin file previously built by the bootloader project.
The easiest way to fix this would be to edit the “Extensions to delete on clean” field for the main project, replacing *.bin with $(TargetName).bin. This will ensure that cleaning (or rebuilding) of the main project won’t affect the .bin file produced by the tutorial project.
Hi,
You should be able to do it by editing the KConfig.projbuild file in the component directory (see the “Blink GPIO number” configuration for the blink sample).
You can find some documentation on this mechanism here: https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/build-system.html
Hi,
The raw terminal needs to be enabled via VisualGDB Project Properties (Raw Terminal page). If the page doesn’t appear, please double-check your VisualGDB edition via Help->About VisualGDB. If you have recently upgraded to Custom edition and the About window doesn’t reflect it, please re-enter your license key in the About window in order to apply the new edition.
Hi,
Each VisualGDB release it tested via ~100 integration tests that verify creating, building, debugging and editing of different project types, hence the problem is likely not caused by a recent VisualGDB update, but is triggered by accidental changes to some global settings (e.g. switching to an incompatible toolchain).
The “unknown QT: serialport” message means that Qt is likely missing the serial port library. You might need to install the library via the Linux package manager and then re-synchronize the sysroot.
If some projects build with the serialport library, while others don’t, the only way to get the old projects to work is to compare the working projects with non-working ones and eliminate the differences.
Unfortunately, as you have not provided any details on the other error messages you got, it is hard to suggest anything specific. If you could attach a screenshot, or the full text of the error, we can help you understand what it means.
Hi,
Please double-check that the main project properly references the bootloader project (per step 11 of the tutorial).
You can also download the source code of the projects shown in the bootloader tutorial here (we have just rechecked rebuilding and it did work as expected): https://github.com/sysprogs/tutorials/tree/master/visualgdb/ARM/BootloaderDemo
Strange. Please try setting the delay to something large (e.g. 1 minute) and then enable gdb logging via Advanced GDB Settings. Once VisualGDB begins waiting for the stub to start (i.e. delaying for 1 minute), please double-check in the gdb session log that the ‘target remote’ command hasn’t been issued yet.
If it is indeed being issued before the delay elapses, please let us know and we will investigate. If it is issued after the delay, please try the following:
- Start OpenOCD manually before the session and switch from “custom gdb stub” to “custom mode”. Check if this works as expected.
- Start OpenOCD via the “custom gdb stub” mode and set a long delay (e.g. 10 minutes). Once the delay counter appears, run gdb manually and try connecting to OpenOCD.
This should help narrow the problem down.
Hi,
The easiest way to do it would be to temporarily edit the linker script file (see the Build page of VisualGDB Project Properties to copy it to the project directory), increasing the memory size to avoid the link error, and then to use the Embedded Memory Explorer for a detailed overview of the memory utilization.
