Forum Replies Created
-
Posts
-
Hi,
Trying out a plain ESP12 sounds like a good idea and should indeed explain whether NodeMCU is causing any interference.
Thanks for the repro project, we have managed to reproduce and fix it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1389.msi
The problem was specific to the “program without debugging” function.
Hi,
The “bad file descriptor” message is shown by OpenOCD after VisualGDB closes the gdb session and is a normal response to the end of session, so aside from being an annoyance, this message is completely harmless and can be ignored.
Normally VisualGDB should not display this text as the session has already ended, but it looks like in some cases this check does not work properly. If you could let us know the circumstances that cause this message to appear, we should be able to fix the check and prevent the message from appearing after the session has ended.
Hi,
This looks like a bug. VisualGDB is designed to always show the timeout window and to be able to cancel the hanging gdb immediately. If you could let us know the exact steps to reproduce the hang, we should be able to fix this quickly.
Hi,
Yes, the gdb stub-based debugging should not be affected by the JTAG wiring issues, so we would recommend trying it if JTAG does not work.
Hi,
Oops, the “NullReferenceException” definitely looks like a bug we would like to fix. Would you be able to describe the exact steps that cause the problem or just send us the faulty project? You can also try building our ESP8266 package on your side: https://github.com/sysprogs/BSPTools/tree/master/DebugPackages/ESP8266DebugPackage. As we had to guess many undocumented parameters with ESP8266, we keep the related code open-source to simplify troubleshooting of issues that cannot be reproduced on our side.
We have tried creating a new project and changing the settings, but could not reproduce the error.
The JTAG problems could be caused by interference from other on-board components. From a quick look at the NodeMCU schematics, it looks like JTAG pins are used to access an SD card, so this could be causing trouble. To make a clean experiment with JTAG, we would recommend attaching the TDI, TDO, TMS and TCK to the ESP-12 module on top of NodeMCU and then physically disconnecting those pins from any wiring on NodeMCU (e.g. cutting the lines on NodeMCU).
Hi,
Normally VisualGDB tries to replicate the RTS/DTR sequence used by the esptool.py in order to reset the board into the bootloader, so it may be a bug related to that mechanism.
We will double-check this on hardware when the NodeMCU we ordered arrives.
Hi,
VisualGDB should be already able to do that (see the “Bootloader activation sequence” field in the Debug Settings), however as we have received feedback that it does not work reliably, we still show the prompt.
Let us know if the programming works without holding the button.
Hi,
Thanks for confirming that the SWO output works. We will consider supporting it more directly in the future versions.
The “GDB Session” window gets activated with VisualGDB wants to display details on slow commands or other long actions. If we did not explicitly activate that window, it would appear that the debug session is stuck and would be confusing. We would recommend placing the Output window and the GDB Session window in different tab groups so that they can be displayed simultaneously.
Regarding the “bad file descriptor”, we are aware of this problem but were never able to reproduce it reliably. If you could provide steps that get a 100% repro, we should be able to fix it.
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.
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?
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.
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.
Hi,
Looks like you are using Resharper that is not fully compatible with GCC-specific code. Please try disabling it for VisualGDB projects.
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.
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.
