[support]

This is strange. __STDC__ should be defined in a gcc_Debug.h file in your project directory and this file should be added to ‘forced includes’ in Visual Studio project properties. Could you please recheck whether the file contains the __STDC__ and whether it’s parsed by IntelliSense?

[support]

The structure of the STL containers can be different in your toolchain. Please go to the GDB Session pane, select “Raw GDB Output”, add your vector to the Watch window, expand it and send us the contents of the GDB Session window. It will contain GDB commands issued by VisualGDB that should explain why STL vector visualization is not working.

[support]

Please try surrounding the library list with -Wl,–start-group and -Wl,–end-group. Note that our latest Raspberry toolchain contains the fix that eliminates the need to specify full path for libraries. You can now simply mention them in the LIBRARY_NAMES; dependent libraries will be included automatically. To use this feature you will need to download the latest version of the Raspberry toolchain.

[support]

Hi,

We have tried to reproduce your problem on our side, but could not. Could you please share the exact bashrc file you have and the error you are getting? Does it happen with stand-alone SmarTTY or only with the one embedded in VisualGDB?

[support]

Hi,

Yes, you can make a workaround. First of all, if you are flashing your program using the bootloader (or any other way that ensures correct FLASH layout), you can simply disable “program FLASH memory” checkbox in VisualGDB Project Properties and VisualGDB won’t touch the contents of your FLASH memory.

Alternatively you can get your bootloader code included into the resulting ELF file during build. This can be accomplished by declaring an array containing your bootloader code, placing it into a separate section and modifying the linker script to put this section at the beginning of the FLASH. I.e. you will first need to generate a file like this from your bootloader image (.bin file, not the .elf file):

__attribute__((section(".bootloader"))) char test[] = {0x01, 0x02, ...};

Then you need to change the linker script to put the .bootloader section before anything else:

SECTIONS
{
.bootloader :
{
. = ALIGN(4);
KEEP(*(.bootloader))
FILL(0xff)
. = 65K;
} > FLASH

...

}

Please double-check everything by reading the .map file (or looking at the generated .bin file).

P.S. The FLASH Security bits mentioned in the previous post are used by Freescale Kinetis devices, so you don’t need to worry about them if you are using STM32.

[support]

Yes, it is possible to configure VisualGDB to place your code starting at a different address. Please see this thread for an example: viewtopic.php?f=5&t=2777
Note that if you are using Freescale Kinetis, the FLASH region at addresses 0x400-0x410 should contain FLASH security bits. If you change your linker script, ensure that the security bits end up in the same place.
Please also note that if you program your project starting at 64KB using VisualGDB, it will fill the first 64KB with zeroes and not just keep them unchanged.

[support]

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 COM4

If 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.

[support]

In 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.

[support]

Hi,

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.

[support]

Hi,

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).

[support]

Hi,

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 address

E.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.

[support]

Hi,

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?

[support]

Hi,

The VS2013 support is added to the upcoming VisualGDB 4.1 release that is scheduled within the next 2 weeks.

[support]

Hi,

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?

[support]

Hi,

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.

[Author]

Posts