Forum Replies Created
June 30, 2020 at 07:21 in reply to: Some Python dependencies must be installed. Check above message for details #28619
According to our records, your support period has expired. In order to continue receiving support, please renew your key here: https://sysprogs.com/splm/mykey
No problem and thanks for letting us know. If you encounter any further issues, feel free to start another thread and we will be happy to help.June 29, 2020 at 18:01 in reply to: Possible bug in VisualGDB 5.7 (Preview 7. Build 3666) #28607
This appears to be related to the new mechanism of storing object files in subdirectories, that allows having multiple files with the same name in the project.
Please try the following build, it should handle this better: VisualGDB-18.104.22.16893.msi
Thanks for confirming this. There might be indeed minor differences between STM32H745 and STM32H747 that could be affecting this. E.g. the M4 core might start suspended and may need to be explicitly started by the M7 core.
If you would like to narrow it down, please consider cloning some of the multi-core STM32CubeMX samples for the Nucleo board, rather than using the default LEDBlink example. These samples come directly from ST and should account for differences between the boards.
Sorry, we are not aware of this issue, however we can suggest a possible explanation and a workaround.
The behavior you described could happen if gdb set software breakpoints in some locations in RAM (i.e. placed the ‘breakpoint’ instruction in specific locations in RAM) and then some of the code would overwrite these instructions (e.g. re-initialize RAM from FLASH again).
If this is the case, please consider setting a hardware breakpoint somewhere in the FLASH memory after the RAM got initialized. Hardware breakpoints will not be affected by RAM overwriting, and once the breakpoint is triggered, gdb will automatically re-insert the RAM breakpoints, repairing the ones that got broken.
If it doesn’t help, please share more details about your setup:
June 29, 2020 at 09:14 in reply to: Cannot edit source files due to missing file permissions #28601
- How exactly do you restart the program?
- What debug tool (e.g. OpenOCD/J-Link Software) you are using?
- Are the broken breakpoints set in FLASH or RAM?
- Does using the “hbreak” command to force gdb to set a hardware breakpoint change anything?
Sorry, the LIBSSH2_ERROR_SCP_PROTOCOL error means that the remote target has rejected the file upload, so the problem is not on the VisualGDB side. Based on what you have described, the problem appears intermittent, so some random circumstances may increase its chance of being triggered.
If the target path is a shared folder that is available on Windows anyway, please consider setting up a manual path mapping instead. See the attached screenshot for more details.
Attachments:You must be logged in to view attached files.June 29, 2020 at 08:41 in reply to: Cannot edit source files due to missing file permissions #28597
Thanks, it looks like the permissions are indeed OK. Please try the following steps to obtain more diagnostic context:
- Open View->Other Windows->VisualGDB Diagnostics Console and enable it.
- Try saving the file again.
- Check the diagnostics console for any error messages produced while saving the file and post them here.
Please note that our technical support is limited to VisualGDB issues only. If you are able to build the project outside VisualGDB, please follow our ESP32 troubleshooting guide to get it to build with VisualGDB as well.
If building the project outside VisualGDB is not working as well, the only way to resolve it would be to do a detailed review of the project itself, and the cost of doing that would quickly exceed what we charge per license. Hence we are not able to include project-specific help with our technical support.
For general help getting ESP32 projects to work please consider posting on the ESP32 forum instead.
Looks like the project you are trying to import is not based on the original ESP-IDF or ESP-ADF, but requires the ESP-VA SDK that may not work with VisualGDB out-of-the-box. You might be able to get it working by addressing the VA SDK-specific issues on your side, however unfortunately we won’t be able to provide any help with this until we officially support this SDK.
We will continue monitoring the traction of the ESP-VA SDK and will consider adding out-of-the-box support for it once it becomes more popular.
No worries, we are happy to help you fix the issues with your project as a part of our consulting services. Feel free to reach out to our sales team to get a quote.
Thanks for the screenshots. Looks like you are using an older version of VisualGDB and an incompatible toolchain.
Please update to the latest VisualGDB 5.5 Preview 7 and follow our ESP-ADF tutorial to create a basic project. Make sure you use the v2.0 release of ESP-ADF, and not the master branch, and also a toolchain based on GCC 5.2.0 (ESP-ADF does not support the latest toolchain).
Once you are able to create a new ESP-ADF project from scratch, you should be able to import existing ones as well.
The best way to convert the project into an MSBuild-based one would be to find a way to dump all the gcc command lines used by the current setup (each Makefile handles this differently, so please check the RIOT OS documentation for more details), and then create a new VisualGDB project from scratch and adjust its build settings to match the captured command lines.
You can find the exact command lines used by VisualGDB to build an MSBuild-based project in the .rsp files.
We also have a detailed tutorial on using .rsp files to troubleshoot imported projects here: https://visualgdb.com/tutorials/arm/import/diagnose/
If you do not want to spend time learning the autotools/Make internals, or porting the project from WSL to Windows-based build tools, please try importing the project as a Linux-based project built with external tools under WSL and make sure the manual build command line matches one that is already working. As long as both VisualGDB and the manual build are using WSL, they should produce identical results.
Please share a screenshot of the Help->About VisualGDB window.
No problem, you can find them here: https://github.com/sysprogs/tutorials/tree/master/visualgdb/ARM/stm32/STM32MultiCoreDemo
Sorry about that. We have double-checked the STM32H745ZI support with the latest OpenOCD and it did work as expected. Please make sure you install the latest VisualGDB 5.5 Preview 7 and update the OpenOCD package and the STM32 BSP via Tools->VisualGDB->Manage VisualGDB Packages.
Please also try erasing the entire FLASH memory of the device via the STM32 ST-Link Utility.
If it still doesn’t help, please share the screenshots of the GUI that is missing the M4 option you mentioned, and we will help you understand what is going on.