Forum Replies Created
-
Posts
-
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.
Hi,
The command should be placed in the “Before launching GDB” list. Then the command will be launched each time you debug and will set the variable for the duration of the debugging session.
Here are the relevant parts of the .vgdbsettings file:
<?xml version="1.0"?> <VisualGDBProjectSettings2 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <ConfigurationName>Debug</ConfigurationName> <Project xsi:type="com.visualgdb.project.linux"> <CustomSourceDirectories> <Directories> <SourceDirMappingEntry> <RemoteDir>$(DirName)</RemoteDir> <LocalDir>e:\temp</LocalDir> </SourceDirMappingEntry> </Directories> <PathStyle>RemoteUnix</PathStyle> <LocalDirForAbsolutePaths /> <LocalDirForRelativePaths /> </CustomSourceDirectories> <CustomDebug> <PreDebugActions> <CustomActionBase xsi:type="SetVariableFromCommandAction"> <SkipWhenRunningCommandList>false</SkipWhenRunningCommandList> <RemoteHost> <HostName>BuildMachine</HostName> <Transport>BuiltinShortcut</Transport> <UserName /> </RemoteHost> <Command>echo</Command> <Arguments>/tmp</Arguments> <WorkingDirectory>$(BuildDir)</WorkingDirectory> <Environment> <Records /> </Environment> <VariableName>DirName</VariableName> <RegularExpression>(.*)</RegularExpression> </CustomActionBase> </PreDebugActions> <PostDebugActions /> <DebugStopActions /> <BreakMode>Default</BreakMode> </CustomDebug> </VisualGDBProjectSettings2>
If this does not help, please send us your .vgdbsettings file so that we could check what is wrong with it.
Hi,
VisualGDB uses the Windows cryptographic service to store the keys. The container name is com.sysprogs.smartty.dsa. You can manage the key from a C# application using the DSACryptoServiceProvider class.
Hi,
This is a known issue. MinGW-based and Cygwin-based executables use different mechanisms of sending a Ctrl-C event. VisualGDB actually allows switching it via VisualGDB Project Properties, but the exact location of the setting depends on your project type. Are you using a regular embedded project? Could you attach a screenshot of your Debug Settings page?
