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

[support]

Hi,

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.

[support]

Hi,

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.

[support]

Hi,

Please reinstall MinGW selecting “C++ compiler” in the installer options. Alternatively you can use a prebuilt package from http://gnutoolchains.com/mingw32/

[support]

Hi,

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.

[support]

Hi,

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

[support]

Hi,

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.

[support]

Hi,

Thanks for pointing this out. We will add an update to our next release. Please let us know whether you need a hotfix before the release.

[support]

Please run the following commands on your Raspberry PI box and provide us with the output:
1. ldd
2. ldconfig -v

Please let us know whether running ldconfig fixes the issue.

[support]

BTW, we have improved our STM32 support in VisualGDB 4.0. A tutorial is available here: http://visualgdb.com/tutorials/arm/stm32

[Author]

Posts