Forum Replies Created
-
Posts
-
For mbed projects the list of memories (e.g. m_ivt) is computed by parsing the linker script, since there is no other source for this information. For MSBuild projects it’s taken from the device definition shipped with the BSP.
Hi,
No problem. We are planning to add a few minor improvements to Live Watch in the next couple of weeks, so we will address this issue as well.
We will post an update here once we get a preview build with the new behavior.
Hi,
The Embedded Memory Explorer reloads the project file when it finishes building, or when you close and reopen the Memory Explorer window. If you believe it shows incorrect data, please try following the steps below to double-check it:
- Create a special build of the ELF file with a specific symbol (e.g. test123)
- Verify that the ELF file actually contains it by running arm-none-eabi-objdump -t [ELF file]
- Replace the output of the project
- Fully close Memory Explorer and reopen it via the command in the View menu
- Recheck whether it shows the newly added symbol
If it still shows the old file layout (e.g. doesn’t show the new symbol), please attach the relevant screenshots and we will help you get it working
Hi,
The Live Watch scales the graphs automatically based on the selected scaling mode (individual vs. combined). The easiest way to get more detail would be to export the data into a CSV file and plot it in Excel or any other similar tool. See the Live Watch documentation for more details about exporting data.
Hi,
We have rechecked the NRFConnect SDK 1.6.0 and it worked just fine with our latest toolchain (GCC 9.3.1). Please try deleting the SDK and reinstalling it with VisualGDB. Please make sure the SDK installation succeeds without any errors (e.g. due to insufficient disk space).
If the problem persists, please share the complete steps to reproduce it from scratch per our problem reporting guidelines, including all the relevant screenshots.
Hi,
The MSP430.DLL file comes from TI and implements the low-level logic for interacting with the TI hardware. In case of any issues with it, we always recommend downloading the latest version directly from TI: https://www.ti.com/tool/MSPDS
Hi,
Please refer to the following page for more information on path mapping: https://visualgdb.com/documentation/pathmapping/
Hi,
Please try restarting Visual Studio after you have changed the theme. This will ensure that all VisualGDB components will pick up the updated colors.
Hi,
Linker script preprocessing could be related to this. Please try linking the MSBuild project using the preprocessed linker script produced by the mbed-cli build.
If it doesn’t help, you can quickly narrow down the problem by combining command lines from different builds. E.g. try linking the object files produced by mbed-cli with the linker command line from msbuild, and vice versa. If the problem appears to be specific to the linker command line, try gradually changing the broken command line until it matches the working one, rechecking the results after every step.
If the problem is triggered by using the object files from MSBuild, please try replacing half of them with the versions built by mbed-cli, and check if it solves the problem. This should help you quickly find the specific object file triggering the problem.
Hi,
This looks like a wiring problem. Please double-check your wiring, clocks and power. If nothing works, please contact Kendryte for assistance, as hardware problems are outside of VisualGDB’s control.
Hi,
Sporadic JTAG errors are typically caused by wiring problems, too fast clocks or unstable power. They are completely outside of VisualGDB’s control, so our best advice would be to try running gdb/openocd manually. If it works better, we can help you configure VisualGDB to match the manual session results. If not, it’s not something VisualGDB could automatically fix.
Hi,
It looks like you have manually edited some files in the VisualGDB debug packages.
Please try deleting the entire %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages folder and creating another project from scratch, letting VisualGDB download all the packages.
Hi,
No problem. VisualGDB offers 2 troubleshooting tools to address this type of issue:
- First of all, you can use the Embedded Memory Explorer to compare the build produced by MSBuild against the build produced by mbed-cli. Most likely, it will be missing some symbols, or using different versions of symbols.
- You can also examine the .rsp files produced by MSBuild and compare them against the mbed-cli build logs. This approach does require substantial time, although it allows tracking down every difference between the 2 build setups and getting exactly the same result as the original project. See this tutorial for a detailed example.
Hi,
Thanks for pointing it out. Indeed, in our test setups, the FreeRTOS.h did not directly include queue.h, so the profiler hooks built without any issues.
We have switched ProfilerRTOS_FreeRTOS.c to reference the FreeRTOS functions in a way that does not depend on the included headers. You can find the details in this commit. The fix will be included in the next update of our profiler framework.
Hi,
This is something to check with Kendryte or Sipeed. VisualGDB uses the OpenOCD port maintained by Kendryte to debug the K210 device, so if it supports this probe, VisualGDB will work with it as well.
If you can confirm that running OpenOCD manually works, we can help you edit the .xml files used by VisualGDB so that it will detect the probe and will show it in the GUI the same way it does it for other supported probes.
When you select Segger J-Link instead of OpenOCD, you are switching to the J-Link debug software – a tool maintained by Segger that allows interfacing gdb to the J-Link. Please check with Segger whether they have any plans for supporting the K210 device – this is completely up to them and is outside our control.
