Forum Replies Created
-
AuthorPosts
-
supportKeymaster
Currently this scenario is not directly supported, although we plan to add it in one of the next releases.
As a workaround you can use any third-party command-line tool that will display the data coming from a virtual COM port and set VisualGDB to show its output when your program is running. E.g. if your device is connected to a virtual COM port available as COM4, go to VisualGDB Project Properties, Custom Debug Steps page, select “Use the following command to start the console” and specify the following parameters:
Command: cmd
Arguments: /c type COM4If your board does not include an external virtual COM port chip (e.g. FTD2xx), you will need to use the USB library on the STM32 device to implement one using the STM32 USB interface. Please refer to STM32 examples for a sample Virtual COM port project.
supportKeymasterIn order to link correctly with the sqlite libraries the file called libsqlite3.so should be present in one of the library directories. You can search for it by running the following command:
cd /usr/lib find . | grep sqlite3
The expected output would be something like this:
./i386-linux-gnu/libsqlite3.so.0 ./i386-linux-gnu/libsqlite3.so.0.8.6 ./i386-linux-gnu/pkgconfig/sqlite3.pc ./i386-linux-gnu/libsqlite3.so ./i386-linux-gnu/libsqlite3.a ./i386-linux-gnu/libsqlite3.la
If all the files are present, but the linker does not find them, please double-check your settings and try restarting the Linux machine. If the problem persists please try creating a simple .c file containing a main() function and build it with the libsqlite library using command line:
gcc file.c -lsqlite3
If you get the same error, please add the -v option to enable the verbose mode and provide us with the gcc output. If command-line compilation works, please compare the basic command line with the command line mentioned in VisualGDB build output.
supportKeymasterHi,
SmarTTY supports 2 types of key-based authentication: using the Windows key container and using OpenSSH format. The Windows key container-based authentication is configured automatically: the key is stored securely (Windows guarantees that only logged on user can access it).
Here’s an example of an id_dsa file in OpenSSH format:BEGIN DSA PRIVATE KEY MIIBuwIBAAKBgQDLYaFjKw55dEKXr9fRYxJyNd3FtZNNbkIydZY6biVlMjkMia1j n2W9AxEMADG+7qEiiJtdK07kj8KGNxebjYqN92iKXJvJ/cD0kwGfqjHa2MyV09ns E9YypM9Z19CnLTXpxTXkDWuG6TviH0kwFCaQ96EijsxMPlU3MfRS8rF9nQIVAPE2 CsyxFEwDNl8hIuDIpupCWzCfAoGARAnujVr0FtjFNU8ovtBCn73MKbt3ttuk5+ad NEaQktN+QQvip0urD2ns4t8DRIKg394oli2lhacr4uP5TTmUXLegtXSLp6vvbe0o i4x2VfcRZq5P7Zo4nypFnx/umaIZLICD5h3/uY5ulVAIDVHvQmPvq0xShVyWbjbf rJ4TxPoCgYEAhOHazGkNOQLvcguFOvKTgHmJxv+0GpzEYLP8nXj0OllR6cMWdWe4 OoKZ+XHGI7WoC9HcC5mQbIMcAJqxXn/+l3eiHgXfiI/8draqVr/hMDHCZ1np5bJx 9SDl0w6iD42/GqykvWiTtIEOXMo9S/jH50eQngoUKUfBOxfVxP9Qu1ACFEFqLgau o6+UGQuog0uq/syNmtKl END DSA PRIVATE KEY
Please note that key files with passphrases are currently not supported.
supportKeymasterHi,
In the example the timer interrupt period is significantly longer than the time required to process the interrupt, so the order of those operations does not matter. In more complex designs where you want to prevent interrupts from re-firing while the old one is still processed, you may want to use various configuration registers of the interrupt controller (e.g. BASEPRI).
Regarding support times, the forum is moderated by sysprogs, however unlike the email support, it’s mostly suited for general discussions rather than urgent/blocking issues. Requests that require external research sometimes take longer to answer. For email requests our policy is to provide an answer within 48 hours, however the average time is less than 12 hours (depending on the time zone).
supportKeymasterHi,
On STM32 and other GCC-based systems the order in which the code/data is placed in memory is controlled by the linker script. You can find the script by looking at the link command line – the script is specified with the -T option. E.g. for the STM32F100VB device the linker script will be in %LOCALAPPDATA%VisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32STM32F1xxxxLinkerScriptsSTM32F100xB_flash.lds
If you want to put a certain function to a given address you need 2 actions:
1. Put the function into a separate section
2. Modify the linker script to put that section at a given addressE.g.to put Reset_Handler at 0x080057f0 you need to modify the linker script in the following way:
.isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) . = 0x57F0; *(.myentry) . = ALIGN(4); } > FLASH
and then put the Reset_Handler into the “.myentry” section:
void __attribute__((naked, noreturn)) __attribute__((section(".myentry"))) Reset_Handler()
You can view the output by adding -Wl,-Map=project.map to LDFLAGS and rebuilding your project. The linker will create a project.map file describing the placement of all code and data in the memory. Here’s a snippet for the new Reset_Handler:
0x20002000 _estack = 0x20002000 .isr_vector 0x08000000 0x5840 0x08000000 . = ALIGN (0x4) *(.isr_vector) .isr_vector 0x08000000 0x1d0 Debug/mystartup.o 0x08000000 g_pfnVectors 0x000057f0 . = 0x57f0 *fill* 0x080001d0 0x5620 *(.myentry) .myentry 0x080057f0 0x50 Debug/mystartup.o 0x080057f0 Reset_Handler 0x08005840 . = ALIGN (0x4)
If you look at the generated .bin file you will see that it consists of a vector table in the beginning followed by zero bytes and the code starts at 0x57f0 address. Note that the second entry in the vector file points to 0x080057f1 (that means 0x080057f0 in THUMB mode). Please also note that the vector table needs to be located in the beginning of the file as the CPU expects it there.
supportKeymasterHi,
It’s hard to tell what exactly is the cause of your problem, without looking at a specific device/board. Here are some general pieces of advice on diagnosing this further:
1. On most devices GPIO pins are multiplexed with peripherals and you need to explicitly switch between the peripheral mode and the GPIO mode. Please ensure that the A5 LED is not configured as an output of some other module.
2. The low voltage output can be a result of the pin working as an input with an internal pull-up resistor enabled. Please recheck that the direction register stays in the OUT mode for that pin.
3. Does anything change if you disable interrupts? If yes, are you sure you are handling them correctly? Can you verify it in the debugger?
4. Can the GPIO/timer output pins accidentally short-circuit anything on your board?
5. Can the perceived 0.4V output actually be a result of rapidly alternating 0 and 1 values (if your timer ISR gets invoked too frequently).
6. Does switching the GPIO numbers (toggle A5 from the main() and A7 from timer) change anything?supportKeymasterHi,
The VS2013 support is added to the upcoming VisualGDB 4.1 release that is scheduled within the next 2 weeks.
supportKeymasterHi,
Will the problem also happen if you stop the target (Debug->Break All) before exiting? If yes, will running “disconnect” command via GDB Session window before exiting help?
September 23, 2013 at 03:50 in reply to: How do I set LD_LIBRARY_PATH for the debugged application? #2122supportKeymasterHi,
Please open VisualGDB Project Properties window, go to the Debug Settings page, select “use custom GDB executable”, click “Customize” and update the “Additional Environment Variables” line.
supportKeymasterHi,
Looks like your file path mapping is wrong. Please run the “bt” command once stopped inside main.cpp to see what path GDB reports. Please provide the output of the “bt” command here so that we could advise you further.
September 4, 2013 at 03:18 in reply to: Needs some deeper understanding of VGDB’s VS integration #2618supportKeymasterHi,
VisualGDB uses the Makefile configuration type in order to allow VIsualStudio use IntelliSense, class diagrams and other similar features just like for normal Makefile-based projects. If you create a new project type and implement IVsBuildableProjectCfg, you should be able to launch VisualGDB for your projects by specifying the VisualGDB port supplier and debugging engine GUIDs in launch options. However in this case you might end up breaking support for IntelliSense and other similar features.
VisualGDB actually has an experimental project extension system that exposes many internal API (e.g. communicating to SSH targets) and allows writing sophisticated build and debug actions in C#. If you could provide us with an overview of your build scenario and explain why the current VisualGDB build process does not cover it, we should be able to help you develop your extension to support it properly.
supportKeymasterHi,
Please reinstall MinGW selecting “C++ compiler” in the installer options. Alternatively you can use a prebuilt package from http://gnutoolchains.com/mingw32/
supportKeymasterHi,
Thanks for reporting this. It is a bug in VisualGDB 4.0r3. Please go to VisualGDB Project Properties, Build Settings page and change Targeted Android Platform from android-15 to android-18. We will release a fix resolving this issue in VisualGDB 4.0r4.
supportKeymasterHi,
Have you added the -std=c++0x flag via the VisualGDB Project Properties dialog? If no, please remove it and add again through the dialog. This will let VisualGDB re-query preprocessor definitions used by GCC and setup IntelliSense accordingly. If everything was detected correctly, your gcc_.h file in the project directory should contain the following definition:
#define __GXX_EXPERIMENTAL_CXX0X__ 1
supportKeymasterHi,
According to the log you posted, GDB can find the symbols for Application::WidthMonitor::CApplication_WidthMonitor class and cannot find symbols for Lib::ImgProc::CLightBar::DetectEdgesFast(Camera::TImageInfo*).
Please check whether the Lib::ImgProc::CLightBar::DetectEdgesFast(Camera::TImageInfo*) function (can be also mentioned as _ZN3Lib7ImgProc9CLightBar11DetectEdgesEPN6Camera10TImageInfoE) contains the source code in the disassembly file. If no, please run objdump on the .o file corresponding to the cpp file containing the Lib::ImgProc::CLightBar::DetectEdgesFast(Camera::TImageInfo*) function and see whether the source is displayed when dumping the .o file.Please note that when running the “info line” command you should put the function name, not the function calling statement, e.g.:
info line Lib::ImgProc::CLightBar::DetectEdgesFast
The “info line” command will display the source line number that corresponds to a given function and can be used to determine whether the source line information is available for the given module.
-
AuthorPosts