[support]

Hi,

You can easily modify add support for a second SRAM as follows:

1. Open VisualGDB Project Properties
2. Go to the Makefile Settings page
3. Locate the “Linker script” field and click “Copy to project directory”
4. Edit the linker script
   1. Add another memory definition
   2. Add rules for placing contents of your SRAM2 sections into the new memory

 

Let us know if you need more details.

[support]

Hi,

The “thread aborted” error does not mean any problems, it simply means that you closed the source file while VisualGDB was still parsing it. Is any functionality broken for you, or are you just concerned with the error messages?

[support]

Hi,

You can try adding the following commands to the GDB startup commands (after target selection) in VisualGDB Project Properties:

file <first.elf>
load
file <second.elf>
load

This will load both images before debugging, however if the images share some of the FLASH pages or if the FLASH driver you are using does a full erase before programming, this won’t work. Then you would need to make a special linker script to join both ELF files into one.

[support]

The answer depends on your setup. If you have the full JTAG connection, you can combine both images into one by editing the linker script and then just debug them as one project.

The easiest way to do this is to convert the entire bootloader binary into a .o file containing a specially-named section and then modify the linker script to place that section at a given address. Let us know if you need more details.

[support]

No problem. You can also use the live variables to somewhat monitor what’s happening with our program without stopping it. E.g. define a set of global counters and watch them while your program is running.

[support]

Sure. Most likely it’s the size of debug symbols then.

[support]

Hi,

You can build an ISO file from a folder by following this tutorial.

[support]

Hi,

This is an unfortunate limitation of the semihosting mechanism. Handling a semihosting call involves stopping the CPU and reading the registers/memory. Due to the USB latencies, this takes tens of milliseconds, so your app will certainly miss some real-time events. The only reasonable workaround we could suggest is to use another UART port to print the diagnostic messages.

That said, it looks like we should be able to create a non-stop semihosting alternative similar to our live variables feature. We will investigate into this and perhaps add it to VisualGDB 5.2 feature list.

[support]

Hi,

We would recommend creating a basic LEDBlink project and testing whether it still runs without debugger. If not, something is wrong with your FLASH programming setup. If yes, try gradually adding features from your current program to the LEDBlink project to see which one breaks the flow.

[support]

Hi,

It’s hard to say why your executable is larger, it could be caused by some code being inlined/expanded, larger symbol tables, or some extra libraries. You can use the objdump tool to figure it out in detail, but if you are targeting Raspberry Pi with 512MB of RAM, 50 KB difference (0.01% of RAM) won’t have any noticeable effect at all.

[support]

Hi,

Yes, the Makefile looks like it can be built with VisualGDB. Simply install our ARM toolchain, add it to PATH and replace arm-none-eabi- with arm-eabi- in your Makefile so that it matches the arm-eabi-gcc.exe executable. However if the project is made to be built on Linux, it might rely on other Linux tools and simply not build under Windows. In that case we would suggest getting a Linux cross-toolchain, getting it to build on a Linux VM and then importing it into Visual Studio as described in this tutorial.

Either way, VisualGDB is flexible enough to build/debug any project that can be built using command-line tools, so you should be able to develop it with Visual Studio and VisualGDB even if it needs to be built remotely under Linux. If you encounter strange error messages, feel free to post them here so that we could try to help you.

[support]

Are you creating a normal VisualGDB proejct using the VisualGDB wizard, or importing some existing code? Are you selecting “FLASH” as the primary memory in the wizard?

[support]

Hi,

Thanks for letting us know. Our Jessie toolchain image was indeed missing some DLLs. We have updated the installer. Please re-download and re-install it.

[support]

Hi,

This is a known limitation caused by the way signals are implemented in Linux. You read more about it on StackOverflow: http://stackoverflow.com/questions/1717991/throwing-an-exception-from-within-a-signal-handler

[support]

Hi,

Yes, we usually update the BSPs quarterly. There are 3 ways to get the updated library:

1. You can build and run our STM32 BSP generator against the new archive from ST.
2. You can simply copy the new code from ST to %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\<…>stm32\<your family> replacing the old code
3. You can convert the project to a stand-alone project and import the code from ST manually.

[Author]

Posts