[support]

Hi,

It looks like the command responsible for the delay is “-stack-list-frames”. This may happen if the algorithm used to discover stack frames does not detect the outermost frame properly and keeps on trying to interpret garbage after the end of stack.

This could be caused by the layout of your program or a bug in gdb, but you can fairly easily limit it by running the following command:

set backtrace limit <number>

where <number> is the maximum number of frames you are interested in. You can start with something like ‘3’ and see if it increases the performance. If this helps, you can add the command to the Additional GDB Commands page in VisualGDB Project Properties.

[support]

Hi,

Sending a repro project should be the easiest. Are you using a Windows cross-toolchain or compiling on the Linux side?

In case of a cross-toolchain we will also need the toolchain archive; in case of Linux compilation we will need a snapshot of %LOCALAPPDATA%\RemoteSourceCache\<machine> in order to reproduce this.

[support]

Hi,

The error you are encountering most likely means that some other library function is compiled expecting that the functions from _divdi3.o will be placed nearby. Adding -mlongcalls to your compilation won’t help as it will not affect the pre-compiled library code. Basically, you have something like this:

If you want to relocate divdi3(), you also need to relocate func1() and any other functions that call divdi3() or are “connected” by shortcalls in the call graph. We don’t know enough about the structure of the internal ESP8266 libraries to give any definitive answer here, but you can try the following process iteratively:

• Relocate one function
• Build, find out the function causing the problem from the error log
• Relocate the offending function as well

Sorry for the inconvenience, but this is the common case with ESP8266.

Regarding ets_timer() we picked it because it was directly called from the user code and would hence illustrate the process well.

[support]

Hi,

Just double-checked the latest STM32 BSP and the StdPeriph sample is available for STm32F072RB. Perhaps your BSP got corrupt? Please try removing and reinstalling it via VisualGDB Package Manager.

[support]

Hi,

The answer depends on the device. Which device are you using?

[support]

Good to know it works. BTW, the fix is included in the latest Beta 2, so feel free to update to it.

[support]

Hi,

Please follow the instructions described in this thread to move arbitrary system functions to FLASH.

[support]

Hi,

Can you try VisualGDB 5.2 Beta 2? We have optimized the thread-related logic in v5.2, so if the threads window is hidden, it should not query and thread information at all and will cache things as well.

[support]

Hi,

Thanks, we’ll look into it and post an update once we can ship a stable build.

[support]

Hi,

Looks like you forgot to specify the -DCMAKE_SYSTEM_PROCESSOR=armv71 as shown on step 18 of this tutorial. Explicitly specifying it in CMake command settings should solve the problem.

[support]

Sorry about that, it may be a bug of the Clang IntelliSense. If it reports that ‘string’ is not a class, please try including <string> explicitly and checking if it still complains about it. If yes, please copy the definition of the ‘string’ class from the <string> file to the source file and check if it ignores it again or complains about another missing class.

Alternatively if you could reproduce it on a small separate example (it should include your toolchain’s include directories) and send it to us, we could investigate it on our side.

[support]

Hi,

Thanks for sharing this. Looks like the Atmel libraries were designed for an older version of the toolchain that did not define _impure_ptr properly. Commenting it out should indeed resolve the problem.

[support]

Hi,

Yes, the missing file can easily declare some functions or types related to the ifstream and break IntelliSense for it. Please try clicking at the error to see which file includes the file.

Perhaps your compiler inserts some implicit preprocessor macro that VisualGDB does not catch, i.e.:

#ifdef SOMEMACRO
#include <somefile.h>
#else
#include <gnu/stubs.h>
#endif

So the compiler includes <somefile.h> and succeeds, but IntelliSense tries to include gnu/stubs.h and fails. Searching your target include directories for stubs.h and checking the code around the relevant #include<> statement should help clarify this.

• This reply was modified 8 years, 9 months ago by support.

[support]

Hi,

We do have a tutorial explaining how to create a basic bootloader with VisualGDB: http://visualgdb.com/tutorials/arm/bootloader/

Hopefully this clarifies the necessary steps. If not, feel free to ask further questions here and we will do our best to help you.

[support]

Hi,

From a quick look it looks like the ST USB library only supports one device class at a time. We would recommend double-checking this on ST forums.

[Author]

Posts