Forum Replies Created
-
Posts
-
Hi,
Looks like a bug, however we could not reproduce it locally. Could you please clarify which project type (Windows/Linux/Embedded) you are using? What happens if you click “Apply” instead of “OK”?
Hi,
It’s a known issue and happens because Visual Studio is trying to write a “clean log” into a file inside the build directory. Normally it’s totally harmless and can be ignored.
If the ONLY difference between the machines is the host name/user name (no toolchain/flag differences), you can use VisualGDB Aliases: http://visualgdb.com/tutorials/linux/aliases/
If you need to change more options, we recommend creating separate project configurations for those targets, configuring each configuration to use a different target and changing them by switching the solution configuration.
Hi,
Yes, you can easily add files in ONE folder with just the Visual Studio’s Add->Existing Item command.
The “Import Folder Recursively” command only simplifies importing of large hierarchies with multiple subdirectories. We have made it available only starting from the Custom edition because we want to keep the price of the Embedded edition extremely low to make it affordable.
Many of the Custom Edition’s features could be replaced with manual scripting (e.g. editing the .vcxproj files in this case), but save time if you are actually using the Custom one. If you believe the saved time is worth the price difference, you can always upgrade your edition via this link: https://sysprogs.com/splm/mykey
Hi,
Sorry for the confusion. Please refer to the screenshot below for details:
Note that $(LocalMultiThreadedBuildFlags) is case-sensitive. It will automatically be replaced with -j(number of CPU cores on your machine) during build.
Sorry, we have disabled the subscription system because somehow spammers were trying to subscribe random addresses there causing us trouble. You can just create a ticket in our support form and we will reply there each time we post a reply here.
The fix is now included in the VisualGDB 5.2 Preview 1: http://visualgdb.com/download/
The new build should add more logging to the Clang IntelliSense Diagnostics Console, so it should show more than just “Object reference not set to an instance of an object”. Could you please double-check the new diagnostics output and let us know if you see anything additional there?
Hi,
Looks like our bug, sorry about that. VisualGDB is trying to create a .bin file from a static library (that is not supported). Please simply disable the .bin file creation for the static library project and the error will go away.
Hi,
We have just rechecked that and could not reproduce the failure. Most likely the bug is actually caused by some GUI not properly displayed in the console mode. We would really appreciate it if you could try creating a project targeting that machine with the normal VisualGDB Project Wizard and let us know if it shows any extra dialogs/confirmations related to SSH. This should help us pinpoint the problem.
We usually update our framework/BSP packages quarterly and are planning to update STM32 ones soon. The solution you described could indeed be used as a viable workaround.
Hi,
The mbed project actually includes a copy of the STM32 HAL framework (in libraries\mbed\targets\cmsis\TARGET_STM\TARGET_STM32xx), so you can theoretically replace it with the one that came with STM32CubeMX and use the code generated by it.
In practice this may trigger compatibility problems between the mbed code that expects an older version of the HAL and the newer HAL take from STM32CubeMX. It should not be anything too complex, but it may not work out-of-the-box.
On the VisualGDB side you can convert an mbed project to a stand-alone one and then switch the files to avoid affecting other projects.
Hi,
AHBPrescTable should normally be defined in system_<device family>.c that is generated by the STM32CubeMX. Please double-check that your project includes it and that it includes the definition of AHBPrescTable.
If it does not, please compare its contents with the system.c shipped with VisualGDB (that comes from the STM32 sample projects) and ensure that your STM32CubeMX configuration includes initialization of the clock module.
Those features are available starting from the Custom edition of VisualGDB. If you have purchased a lower edition and want to use them, you can always upgrade. Simply contact our sales and they will give you an upgrade quote and a purchase link.
Hi,
VisualGDB uses the default reset sequence from the Espressif’s esptool.py, but you can override this in the Debug Settings. Simply change the default bootloader sequence (!DTR;RTS;SLEEP;DTR;!RTS;SLEEP;!DTR;SLEEP) to the one that will work with your wiring.
If you cannot get JTAG to work reliably, we recommend using the ESP8266-EVB board from Olimex. It appears to be generally more reliable than the original ESP-xx modules.
