Forum Replies Created
-
Posts
-
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.
Hi,
Sorry for the delayed reply. Looks like there was a bug in our template exporting mechanism. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.936.msi
If it still does not work, please let us know.
Hi,
We are sorry about this bug. To diagnose it quickly we have added extra error logging to this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.916.msi
Could you please try it and let us know if the problem still persists and what error message is shown if it does?
Hi,
We now have a preview build of VisualGDB with the new advanced memory window feature. The new memory window contains workarounds for J-Link stub crashes, can read memory using the live engine while the program is running, allows highlighting global variables, functions and stack frames and is integrated with the Live Variables and Visual Watch features. You can try the preview build here: VisualGDB-5.2.5.916.msi
Hi,
It is strange that the gdb does not react to Ctrl-C/Ctrl-Break properly. If there is any reason why the workaround you discovered does not work, you can try clicking “Setup advanced GDBServer settings” on the Debug Settings page and then selecting “Break All sends Ctrl-C to gdbserver”. If you discover further problems, feel free to contact us again.
Hi,
Looks like the ST-Link might be leaving the target in a state where it does not respond to SWD requests properly. Please try unplugging/replugging the JTAG programmer and check if the problem also happens when programming a basic “Hello, World” program. Perhaps something in your firmware interferes with the debug unit.
