Forum Replies Created
-
Posts
-
Sorry, we have tried reproducing this for the latest supported ESP-IDF version (4.0), but could not get the behavior shown in the video.
If you could confirm that the problem persists with ESP-IDF 4.0, please share the full repro steps from creating a project. If the problem is specific to ESP-IDF 4.1, please consider editing the configuration manually until ESP-IDF 4.1 reaches the “stable release” stage and is officially supported by VisualGDB.
Sorry, we are not aware of this issue. Please try checking if other variables get overridden as well (e.g. by running ‘set’ instead).
If this doesn’t help, please try creating the most basic repro project and share it with us so that we could try replicating this. That said, please also ensure the VS instance you are using doesn’t inherit some custom environment and that your environment block doesn’t exceed Windows limits.
Hi,
No problem, we have rechecked the latest EFM32 SDK (5.8.3) and updated the VisualGDB’s EFM32 BSP to match it.
Please update it via Tools->Manage VisualGDB Packages and you should be able to use the new devices.
No problem, please try this build: VisualGDB-5.5.1.3294.msi
We have added a context menu command “Set as Main Component” to the ESP-IDF component items in Solution Explorer for CMake projects. Flagging an arbitrary component as the “main” one will now merge its contents directly under the top-level item in Solution Explorer.
Hi,
Real-time variables are included in the Custom edition of VisualGDB and higher. If you are using a lower edition, you can upgrade it here: http://visualgdb.com/buy/
If you are using VisualGDB Custom, please share a screenshot of the Help->About VisualGDB window and a screenshot of the Visual Studio window with the Debug->Windows menu open and the VisualGDB-based items missing and we will help you get them to appear.
Sorry, we have researched the complexity of supporting custom boards with Analyzer2Go and created a detailed checklist and plan, however due to other feature requests received for other products, we are currently not able to allocate any time for this in the nearest time frame and will have to wait until the Analyzer2Go user base grows more before proceeding with this feature, sorry.
Sorry, we have tried reproducing the issue on a clean machine, but could not get anything to fail
The problem might be caused by a conflict with some other package versions installed somewhere else (see the directories listed in the build command line, such as C:\Program Files (x86)\Arduino/hardware).
Please try the following steps to resolve this:
- Try clearing the Tools->VisualGDB->Arduino->Arduino IDE Directory setting.
- Try clearing any other directories mentioned in the build command line.
- Confirm that the problem exists for a freshly created demo project and is not specific to one pre-existing project, that could be referencing some libraries incorrectly.
If nothing helps, please try running the build from the Arduino IDE under Process Monitor and enable filters for “Process Create” event. It will show the command line used by the Arduino IDE to launch arduino-builder (you would need to locate the instance that has -compile among the arguments). The differences in the build results are likely triggered by the differences in command lines (e.g. the Arduino IDE passes some paths in a different order).
Please try comparing the command lines and then adjusting the VisualGDB’s command line to match the one captured from Arduino IDE and running it manually via Command Prompt. If you can find a specific argument, or argument sequence that triggers the problem, we should be able to update VisualGDB to avoid it and produce the same results as Arduino IDE does.
Hi,
Please ensure you are using the Advanced CMake Project Subsystem. Then you will be able to use the automatic header discovery to fix the project settings automatically.
If you prefer to configure everything by hand, you would need to find the target (i.e. an library or an executable) that contains the faulty source file and add the directory containing the source file to its include directories under VS properties for that target.
If you still cannot find the corresponding settings, please let us know your project type (Advanced CMake/Regular CMake) and we will provide more detailed instructions.
No worries. Unlike the stable v5.4 release, the development branch of VisualGDB (v5.5) is indeed less stable, some of new/changed functionality has been fully tested yet. That said, as long as we receive sufficient details in order to pinpoint/reproduce the issues, we are usually able to release fixes relatively fast.
Thanks for checking the $sp value, it helped us factor out the most probable cause of this issue. RAMBASE + 0x2000 is actually correct (on ARM devices, $sp is decremented before pushing the value into the memory so that it will point at the latest value pushed in the stack, so pointing at exactly the end of RAM is correct).
We have done some further comparisons on our side and identified the problem. It turns out, the development branch of VisualGDB that included experimental support for the IAR compiler was incorrectly passing target-specific flags to the linker, so the linker chose an incorrect version of __libc_init_array().
We have fixed it in the following build: VisualGDB-5.5.1.3292.msi
Please rebuild your project after installing it.
As we have previously suggested, please double-check the values of $pc and $sp against the values shown in datasheet (or the values used by the Keil project). If they turn our incorrect, we should be able to easily fix it.
Hi,
The “jumps to invalid address” would happen if the target address of a jump instruction was not listed in the disassembly output produced by the objdump tool. This might indeed happen with some combination of section flags and linker script rules, however we would need to know more details in order to reproduce/fix it.
If you could attach a basic repro project (ensure you remove the .vs and VisualGDB folders containing large generated files), or describe the exact repro steps (the address of the new memory, the exact changes to the source files), we should be able to reproduce and fix the problem promptly.
Unfortunately, the video hosting you used doesn’t seem to work (video freezes after about 3 seconds of playback). Please try using a different hosting.
No problem, we can suggest a few tricks:
- You can always simply hardcode a breakpoint in the code (asm(“int3”) for x86 or asm(“bkpt 255”) for ARM). This will stop gdb once the corresponding piece of code is executed regardless of the symbol load status.
- Alternatively, setting breakpoint in your function by its name (via Debug->Windows->Breakpoints->Add) may work even without loading symbols (ELF symbol tables are separate from DWARF symbols), although it depends on the gdb internals and we have not explicitly tested this assumption.
- If you could share a detailed gdb log (with timings) from a session showing slow symbol loads, we might be able to add logic for detecting slowly loading symbols and displaying some GUI allowing to stop them from auto-loading.
- Finally, you can try using gdb index files to speed up symbol loading. We are currently looking into managing index files automatically and would appreciate your feedback on real-world project performance difference with/without using those files.
Strange. Normally the arduino builder should have displayed more details.
Either way, please try deleting/moving out the C:\Users\Johanan\AppData\Local/Arduino15 folder and then create another Arduino project for that target. This will force VisualGDB to re-install all the libraries and resolve any inconsistencies that could have been left by the previous setup.
