Forum Replies Created
-
Posts
-
Hi,
Looks like the absolute Windows-style path got hardcoded into your application. Please try specifying the library name/directory separately in your linker arguments, i.e.:
-LC:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\opt\Iddk2000_3.3.0_ERelease_C++_Raspbian\sdk -lEIddk2000
Which board are you using? What happens if you then unplug the board and plug it back? Does the new program start normally, the old program start normally, or does nothing happen at all?
Hi,
Sorry for the late reply. We have published a detailed tutorial on importing CooCox projects into Visual Studio: http://visualgdb.com/tutorials/arm/coocox/
The exact answer depends on the debug method you are using. Generally each method provides a setting that allows selecting whether you want to program the firmware or assume it’s already programmed.
If you are not sure, let us know which debug method you are using so that we could help you locate the settings.
Hi,
Normally the extra initialization code should be placed into a separate Embedded Framework, not into the sample.
If you absolutely need to make it a part of the sample, you can add the following element to the EmbeddedProjectSample element in the sample.xml file:
<DoNotUpgradeCToCpp>true</DoNotUpgradeCToCpp>
Hi,
The BSP cannot override those settings, however the BSP can define embedded frameworks that can be referenced by the project and the frameworks may in turn define extra files and flags.
In fact, our BSP-related code is open-source, so you may find some useful examples here: https://github.com/sysprogs/BSPTools/
Hi,
The dongle does not seem to be very popular, so we won’t be adding a special plugin for it in the near future. However if there is a gdb server that supports it, you can configure VisualGDB to use it by selecting the “Custom GDB Stub” in the debug method selector. If that does not work, feel free to post the problem description here and we will try to help you get it to work.
Hi,
This looks like a connection problem. Please double-check that all the JTAG connections (TDI, TDO, TMS, TCK) match the layout used with the EVB board. Also try resetting the board manually, but ensure that the reset is disconnected from the JTAG reset (xt-ocd has a bug with the reset on FT2232-based programmers). Finally try lowering the JTAG rate to 1 MHz or even lower.
Hi,
The easiest way to do both would be to remove all files from solution explorer and re-import them via right-click->Add->Import Folder Recursively. There you can also enable an option to bypass the Source Files/Header Files folders.
Hi,
We have just rechecked the latest toolchain with another Cortex M3 MCU (STM32F100VB) and could not reproduce the problem, so the fault is not caused by ARM vs Thumb problem.
In order to pinpoint the problem, please use the call stack window together with the disassembly view to find a specific instruction that causes the fault. If this is not helpful, open the Disassembly view before stepping into __libc_init_array() and then step into it, doing one instruction at a time until the fault occurs. If the fault happens on a memory accessing instruction, please check the address used in that instruction. If it is outside the FLASH/RAM ranges, something got wrong with the memory map (e.g. a bug in the linker script or a wrong address somewhere).
Hi,
Unfortunately, compiling individual files is not yet supported. VisualGDB uses GNU Make as the build system and in this mode Visual Studio can only pass “build project”, “rebuild project” and “clean project” commands, but not individual file commands.
Hi,
Please try locating the file that defines the UtilInit() function. If it is a C file, ensure that the declaration in the .h file (or the #include<> directive including the .h file) is wrapped with extern “C” {}.
