[support]

Thanks for confirming this. Based on our knowledge, the STM32 SDKs have always supported FreeRTOS instead of RTX, so our project examples are based on it as well.

It does not mean that you cannot use RTX on STM32 projects, but you would need to setup the project manually, import the necessary source files and possibly change some sources to support STM32 hardware properly. We don’t provide any RTOS versions beyond the ones provided by the SDK vendors, but you should be able to find 3rd-party project examples online as the STM32 devices are very popular.

[support]

Hi,

Normally if a gdb command takes too long, VisualGDB should show a popup window allowing to cancel that command. Does it appear in the case you are describing?

[support]

Hi,

This could be a problem with the baud rate. If you have the gdb stub enabled and initialize it properly, it should print the following output to the serial port after you restart it:

$T05#b9

If you don’t see this, either the baud rate is incorrect or your program does not start properly. If the FLASH programming succeeds, please try programming a “Blinking LED” project. Does the LED start blinking? If not, please try changing the FLASH mode on the Debug Settings page of VisualGDB Project Properties as your board may use a different FLASH type.

[support]

Hi,

OK, we just got the notification that the NodeMCU got shipped, however the expected arrival date is March 21, so it will probably be faster to solve this iteratively rather than wait for the board to arrive.

The 912-byte difference comes from the padding esptool.py adds to the file and it should be causing any troubles.

The bytes at offsets 2 and 3 encode the FLASH memory parameters used by ESP8266. The only source of documentation we could find was the esptool.py from Espressif:

        flash_mode = {'qio':0, 'qout':1, 'dio':2, 'dout': 3}[args.flash_mode]
        flash_size_freq = {'4m':0x00, '2m':0x10, '8m':0x20, '16m':0x30, '32m':0x40, '16m-c1': 0x50, '32m-c1':0x60, '32m-c2':0x70}[args.flash_size]
        flash_size_freq += {'40m':0, '26m':1, '20m':2, '80m': 0xf}[args.flash_freq]
        flash_info = struct.pack('BB', flash_mode, flash_size_freq)

Based on this,  “02 00” means “FLASH in DIO mode, 4 megabits, 40 MHz” and “40 20” means “32 megabits, 40 MHz” and an unknown FLASH mode. This could be related to the problem you are experiencing, so please try experimenting with the FLASH mode in VisualGDB Project Properties. Wrong FLASH mode would be consistent with what you are describing: the programming would succeed, but the chip would not start. If none of the modes work, please try using our ESPImageTool.exe to make 2 binary images from the ELF file and then manually put the 0x40 value at offset 2. Perhaps this is some undocumented value that is required on NodeMCU.

The split into 2 images (e.g. at 0 and 0x10000) comes from the ESP8266 linker script file:

MEMORY
{
  dport0_0_seg :                        org = 0x3FF00000, len = 0x10
  dram0_0_seg :                         org = 0x3FFE8000, len = 0x14000
  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40201010, len = 0x6B000
}

The data/code at the beginning of FLASH is loaded into RAM by the bootloader and the code at 0x200000 is directly executed from FLASH. You can quickly check if your image also has 2 areas by running “xtensa-lx106-elf-objdump.exe -h <ELF file>”:

  0 .data         00000370  3ffe8000  3ffe8000  000000e0  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  1 .rodata       00000138  3ffe8370  3ffe8370  00000450  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .bss          000062b8  3ffe84a8  3ffe84a8  00000588  2**4
                  ALLOC
  3 .irom0.text   0002f5a4  40210000  40210000  00007170  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .text         00006be4  40100000  40100000  00000588  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

The 0x40200000 corresponds to the beginning of the FLASH memory and the .ir0m0.text section loaded at 0x40210000 will be programmed to FLASH at offset 0x10000). It’s hard to say why VisualMicro produces a binary that does not use 2 sections; perhaps they use a customized linker script that puts the sections adjacent to each other. We purposefully use the unmodified scripts from the ESP8266 SDK to maximize compatibility with existing projects.

[support]

Hi,

Looks like you are using Resharper that is not fully compatible with GCC-specific code. Please try disabling it for VisualGDB projects.

[support]

Hi,

The RTX/FreeRTOS switch actually comes from the device manufacturer. VisualGDB examples are based on the ones included in the original device SDK and if a certain feature is discontinued in the newer SDK version, VisualGDB will drop it as well. If you let us know the exact device you are using, we may be able to point you to an older SDK that supports RTX.

[support]

Hi,

The experience we got with OpenOCD, ST-Link and SWO was that after a while the ST-Link suddenly stopped working until we physically re-plugged it. It was also very inconsistent – sometimes it worked, and the other time it did not, so it looked like some bug of the ST-Link firmware. As we tried it more than a year ago, it could have been fixed in the latest ST-Link firmware.

Regarding the launcher output, please consider putting your program to Custom Debug Steps -> Remote Console -> Use the following command to start the console. It will put your program to a separate pane in Visual Studio and will provide better experience than just the launcher output.

 

[support]

Hi,

No problem, we could add a tutorial. Let us know which project you are trying to import and we will see if we can make a detailed tutorial on that.

[support]

Hi,

Sorry, when it comes to ESP8266 and ESP32, each new version of the framework comes with its own set of issues, so we only officially support the ones that we retest and repackage. You can try experimenting with different settings and libraries at your own risk to get it to work, or simply wait until we repackage the final esp-idf release and resolve all the issues we discover. As it requires substantial effort on our side to resolve those issues each time, we only do that for major SDK releases. Sorry.

[support]

Hi,

Please check the OpenOCD window for errors related to FLASH programming. This should explain why the initial programming fails.

Please also double-check that you are not comparing the .user_data section after it is rewritten by your program and no longer matches the contents recorded in the ELF file.

[support]

Hi,

This happens because the esp-idf repo does not actually contain all the libraries. Instead they are automatically downloaded first time you build a project with it.

Hence the recommended procedure is to build one of the sample projects from esp-idf on Linux and then copy the esp-idf directory on Windows and try generating a BSP from it.

We will look into updating our ESP32 toolchain once the esp-idf 2.0 reaches the final release stage.

[support]

Hi,

Perhaps something in your setup is removing the environment variable before launching msbuild?

Please try running “echo %VISUALGDB_DIR%” just before launching MSBuild. This should output the VISUALGDB_DIR variable.

[support]

Hi,

This is by design. VisualGDB relies on Visual Studio to handle the project dependencies. Please either create a .bat file that will build all the projects, or build the .sln file by running devenv.exe or msbuild.exe from command line.

[support]

Hi,

Thanks. Are you using the latest VisualGDB 5.2R8? If not, please try updating. You can also force VisualGDB to update the file references by clicking on a different MCU on the first page of VisualGDB Project Properties and then selecting the current one back and pressing “Apply”.

[support]

Hi,

This is indeed strange. Could you please attach your .vgdbsettings file or send it to us via the support form? This should help us see if this is a VisualGDB bug.

[Author]

Posts