[support]

Hi,

Does the project output any errors to the console? Did you copy the code from the tutorials EXACTLY, or did you modify it? Perhaps you have accidentally bypassed some initialization?

Normally missing libraries should cause link-time errors, but not run-time issues.

Alternatively you can try the same project on a different VM (you can use Vagrant to just download a ready image with some recent OS in just a few clicks).

[support]

Hi,

Yes, the global settings like board type are managed per-project. However they are just convenient shortcuts for things stored in nrf5x.mak and debug.mak/release.mak, so you can simply take the -DPCAxxxx setting from nrf5x.mak and put it into per-configuration .mak files modifying each one individually. The only pitfall is that editing global settings in the GUI will regenerate the global .mak file.

[support]

Hi,

Yes, please try running it as root. If this does not help, double-check your camera connection, settings and try some other command-line tool for capturing images.

[support]

No problem. Enjoy VisualGDB 🙂

[support]

Thanks, we have reproduced it. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.4.684.msi

[support]

Hi,

Currently it is only supported with the Embedded projects that are built locally.Is there any reason you cannot setup a locally built project for your target?

We could also add experimental support for virtual threads to Linux projects if this helps.

[support]

Hi,

The easiest way to do that would be to just reinstall the toolchain to c:\ again. The installer will update the registry automatically.

[support]

Hi,

Yes, it could be that some access control settings were interfering with saving the changes. If you encounter further problems, feel free to open another topic.

[support]

Hi,

First of all, please try running the project on the Linux machine. Does the GUI show correctly? If no, the problem is in the project and not in XMing.

If yes, please try creating a basic Qt project and OpenGL project. If the first one does not show properly, it looks like an Xming bug. If the second one does not, you may be missing OpenGL support.

[support]

No problem. If you run into any any further problems, feel free to open another topic.

[support]

Sure, but please note that you do it at your own risk. Doing this may result in random crashes, bugs and strange behavior in production code.

1. Enable the generation of a .map file in VisualGDB Project Properties
2. Identify a particular symbol that you want to move to FLASH (json.a does not get included anywhere, so we’ll move ets_timer_arm_new that does). You can find the biggest symbols via Embedded Memory Explorer.
3. Build the project and locate the symbol in the linker script:

    .text          0x4010016c      0x3d8 f:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/lib\libmain.a(ets_timer.o)
                                   0x450 (size before relaxing)
                   0x40100244                ets_timer_setfn
                   0x40100328                ets_timer_disarm
                   0x401003d8                ets_timer_arm_new

4. Copy libmain.a to libmain_fixed.a
5. Run the following commands to extract ets_timer.o from libmain_copy.a, rename .text to .irom0.text and put it back:

   xtensa-lx106-elf-ar x libmain_fixed.a ets_timer.o
   xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text ets_timer.o
   xtensa-lx106-elf-ar r libmain_fixed.a ets_timer.o

6. Replace “main” with “main_fixed” in esp8266.mak (it will get reverted back once you edit anything in VisualGDB Project Properties, so you can instead rename libmain.a to libmain_orig.a and edit libmain.a).
7. Check the map file to see how it got moved to ROM:

    .irom0.text    0x40240000      0x3e4 f:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/lib\libmain_fixed.a(ets_timer.o)
                                   0x450 (size before relaxing)
                   0x402400dc                ets_timer_setfn
                   0x402401c4                ets_timer_disarm
                   0x40240278                ets_timer_arm_new

[support]

The Output tab contains the error messages formatted so that Visual Studio can understand them. VisualGDB reads the messages from the compiler, recognizes them using regexes and prints them back using the format used by Microsoft’s compiler, so VS can display them.

If you want to see the raw messages, simply run ‘make > log.txt 2>&1’ from the command prompt in your project directory and then look into the log file.

Let us know if you need more details.

[support]

OK, perhaps this is VS-specific? Which VS version are you using?

[support]

Hi,

We are aware of that and will include a fix in the next maintenance release. If this is critical, we can also upload a daily build with this fix.

[support]

Hi,

Yes, the libraries we provide (that come straight from the Espressif’s SDK) are compiled in a way that occupies most of the RAM. You can try hacking them (with extracting individual objects from .a files to .o files and renaming sections) to move some rarely functions from RAM to the IROM section.

We have also heard people disabling the instruction cache and successfully using another 32K block of RAM after the first 32K, but we have not tried it ourselves and are not aware of the potential performance or stability impact.

[Author]

Posts