Forum Replies Created
-
Posts
-
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.
Hi,
It’s hard to say for sure what is causing it, but we can suggest a few possible causes:
- Please double-check whether the code and stack location (evaluate $pc and $sp in the watch window) make sense (i.e. fit into FLASH and RAM of the device respectively). Please try locating the exact device name printed on the chip and double-check its datasheet. Accidentally selecting a different device while creating the project would lead to this type of error.
- Please try creating a “Blinking LED” project with the correct port settings (of an actual on-board LED), program it, verify the FLASH memory contents and try plugging the board into another power source to see whether the LED starts blinking. Sometimes unreliable JTAG/SWD connection, or unreliable power cause weird behavior similar to what you have described.
Please check the part of the build log before the “Command exited with code 1” line. It should show the actual error message coming from the arduino-builder tool.
Hi,
Please try this build: VisualGDB-5.5.1.3289.msi
Then open the main source file and check if VisualGDB suggests cleaning up redundant Arduino packages. If yes, please proceed with the cleanup.
If not, please try building the project and share the output from the View->Output->Build view (the screenshot you attached shows the output from VisualGDB Advanced Project Subsystem that is different).
Thanks for confirming your support status.
Normally, VisualGDB would display the sources of each component under a corresponding entry in the “Components” view except for the component called “main”. The contents of “main” is shown directly under the project item for convenience.
Based on the screenshots it looks like VisualGDB could not find the main component anymore, so picked up the first component reported by ESP-IDF and merged its contents directly underneath the project view instead.
Normally, we would advise keeping the “main” component name if you decide to move it into a different folder, as it clearly indicates which of the component contains the startup code and makes the project structure easy to read. We could also add an setting that would allow overriding the main component name by editing the XML contents of the .vgdbcmake file, although we would generally advise keeping the main name for readability.
Good to know the USB device display works. The “unable to find CMSIS-DAP device” issue is a bit trickier. Generally, when VisualGDB detects multiple instances of the same debugging interface, it issues a special command to OpenOCD (cmsis_dap_serial for CMSIS-DAP devices) in order to pick a specific one.
If this doesn’t work, either VisualGDB determined the serial number incorrectly, or OpenOCD fails to handle it.
In order to fully track this down, you would need to build OpenOCD from source (see this tutorial), configure it to run the “cmsis_dap_serial” command and step into the logic responsible for handling it and filtering devices by serial numbers. If it turns out VisualGDB is passing the serial number incorrectly, please let us know more details and we should be able to fix it.
If the problem is on the OpenOCD side (e.g. it tries to query the serial number from the HID-level device instead of the USB-level device), feel free to submit a merge request with the fix to our OpenOCD repository and we will include it in the version we ship with VisualGDB.
We can also do all the investigation and OpenOCD fixing for you, however as it involves troubleshooting external tools and hardware, this would be a subject to a customization fee. Please feel free to contact our sales to get a quote if you would like us to handle this for you.
Thank you for your inquiry. Unfortunately, the description you provided does not sufficient details for us to reproduce the problem or pinpoint its location. Please describe the issue using the 3-step format shown here.
Please use accurate and precise descriptions for all the settings you change in the wizards and property pages, and also make sure describe the exact modifications you do to any configuration files.
Once we have a clear sequence of steps that allows reproducing the problem on our side, we are usually able to release a hotfix or advise a workaround promptly.
No worries. The logic we added for elimination of the duplicate entries does compare the serial numbers, so normally having 2 different physical devices should show them correctly.
Please try this build: VisualGDB-5.5.1.3287.msi
Please try enabling View->Other Windows->VisualGDB Diagnostics Console, then open the device list, confirm that there is just 1 device instance, while 2 physical devices are plugged in and click on the “copy to clipboard” link on the device entry. This will produce a detailed log of enumerating the USB devices and eliminating the duplicates to the VisualGDB Diagnostics Console. Please share the output from that window and we should be able to understand what is going on and fix it further.
Hi,
This is normally something managed by the OpenOCD tool. As its support for ST-Link is maintained by ST’s engineers, they may eventually merge this into the mainline OpenOCD repository and then VisualGDB will display this warning as well once it picks it up from OpenOCD.
Strange. Please try installing an older version of the package, locate the directory where VisualGDB installs it (it will appear in the “installed” list) and remove the entire parent directory (that contains both package versions). Then delete the %LOCALAPPDATA%\VisualGDB\ArduinoPackageCache directory and reinstall the latest package. This should clear any incorrectly cached data and get the package to appear again.
