Forum Replies Created
-
Posts
-
Hi,
Unfortunately we are not aware of anything that could be causing this, but we can still help you pinpoint it. First of all, please check whether the problem can be reproduced:
- When building from Visual Studio
- When building the default target only (no /t switch)
- When building a clean “Hello, World” project using the same toolchain
- When building a remote “Hello, World” project
- When building a regular VC++ Win32 project
Please let us know your findings and we can suggest further steps to narrow it down.
Hi,
It looks like the executable is either corrupt, or is blocked by your antivirus. Please try re-downloading it from http://gnutoolchains.com/esp32/ and running it again and check your antivirus logs if it doesn’t help.
Hi,
Sorry, that’s unfortunately by design. Each embedded framework managed by VisualGDB includes all of the source files from the corresponding directory. The ST samples (selected as “STM32CubeMX Samples” on the sample page) often include a subset of the sources from a particular framework that is used in this particular sample. This makes them incompatible with the framework mechanism out-of-the-box.
We generally recommend using the vendor samples (e.g. STM32CubeMX samples) to quickly explore various drivers and libraries that come with the SDK and then creating production projects based on the regular samples that are compatible with the framework system. Alternatively you can simply reference the necessary frameworks and manually remove the conflicting files from the regular source file list.
We don’t do the adjustment automatically as a part of our BSP generation, as we want the vendor samples to be 100% equivalent to the original ST projects they are based on in order to minimize the chance of introducing errors. Unfortunately this means inheriting the monolithic non-modular structure of the original projects.
Hope this explains. We can also share more detail on the inner workings if the samples, BSPs and frameworks, so you would tweak them to your needs.
With the barebone project, there could be several variants of it for different cases (e.g. with different linker scripts/startup files/system files), so instead of providing a separate barebone sample, we recommend using the VisualGDB project template mechanism. Simply start with the LEDBlink project, remove all code and the unnecessary frameworks and then export it as a VisualGDB template via the File menu. Next time pick “create a project from template” and VisualGDB will automatically copy the project structure. You can also tweak the template files after creating them, as they are simply ZIP files with an XML index + the referenced source files.
Hi,
There was a temporary issue with the R12 file on our server, sorry about that. Please try downloading it again.
Hi,
Thanks for reporting this and sorry for the inconvenience. We have double-checked the installer file and resolved the problem. You should be able to install it as usual now.
Hi,
No problem. With the reset sequence, you might be able to reset it by first triggering a bootloader reset (same as when programming FLASH), and then immediately issuing an “exit bootloader” command or programming an empty image without erasing. Checking the bootloader sources might help find the exact commands or suggest a better idea.
With hardware debugging, if the board has the JTAG or SWD pins exposed, the Olimex debugger should work.
We have also added an option to control the vertical scrollbar in the console to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2430.msi (under Tools->Options->VisualGDB->General->GUI). The default colors unfortunately would be trickier, so we will try to add an option for them next time we redesign the terminal settings logic, but we won’t be able to add this option in v5.4.
Hi,
No problem and thanks for reporting this. Looks like one of the components in our toolchain was using files from an earlier build. We have fixed it and published an updated toolchain. Please update to the R12 toolchain via VisualGDB Package Manager.
Hi,
Most likely your cross-toolchain is out-of-sync with the target SD card image. Please ensure you are using a compatible toolchain/SD image combo (see this page for supported versions).
Hi,
No problem and sorry we couldn’t offer further help with this. That said, if you discover that mbed itself works on a different target, but doesn’t work under VisualGDB, feel free to share the details here and we will help you get it to work with VisualGDB.
Hi,
Strange. The MSBuild-based projects use a different mechanism for locating the toolchain property sheets, although it should be automatically synchronized to the mechanism used for GNU Make.
Could you please share your %LOCALAPPDATA%\VisualGDB\FindToolchain.props file and the .vcxproj file so we could check for possible causes of this?
Hi,
Sorry about that, looks like the previous build was missing the Arduino builder component. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2428.msi
Hi,
This is something managed by mbed itself and not directly by VisualGDB, so we would advise checking mbed documentation and perhaps creating a thread at the mbed forum.
Hi,
Thanks for your feedback. The “build and Flash” issue might be caused by a timing error somewhere in the FLASHing logic. If you could share the output from an unsuccessful FLASHing operation, we might be able to tell more. We could also add a delay setting between the completion of the build and FLASHing.
With samples, thanks for the suggestion. We will consider searching more directories for samples in one of the next VisualGDB versions, although we won’t change this logic now due to our release schedule.
You can change the colors of the Arduino terminal via the corresponding page of VisualGDB Project Properties (you need to enable it first). We have added an option to change the inactive color to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2427.msi
We have also double-checked the behavior for failed FLASHing, however could not reproduce any problems. Could you please share the internal output from such a session? Perhaps the underlying tool still exits with code 0 despite the error?
With terminal reset sequence, this is specific to your Arduino board. Please check its schematics and Arduino forums/documentation. Most likely there is a sequence of events (e.g. setting/clearing signals like DTR) that lead to a reset. Once you find that sequence, let us know and we can help you configure VisualGDB to use it.
