ESP8266 – failed to connect to GDB stub

[parsec67]

I have an Olimex MOD-WIFI-ESP8266-DEV which I have worked on for over a week using GDB stub debugging. Today I was doing a final test that involved calling SDK function system_restore() to erase WiFi credentials that are stored after a successful smartconfig.

After doing this I am unable to debug in VS. Flashing the chip works but that is about it. VisualGDB reports unable to connect to GDB stub after hanging for a while. Here’s the last part of the error:

 

-gdb-set disassembly-flavor intel
^error,msg="No symbol \"disassembly\" in current context."
-gdb-set print demangle off
^done
-break-insert -f main
&"Function \"main\" not defined.\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="main",times="0",original-location="main"}
Warning: could not set a breakpoint on main. 'Step into new instance' will not work.
-break-delete 1
^done
Found an SPI FLASH section at 0x00010000. This image is a non-OTA image.
set serial baud 74880
&"set serial baud 74880\n"
=cmd-param-changed,param="serial baud",value="74880"
^done
target remote \\.\COM8
&"target remote \\\\.\\COM8\n"
~"Remote debugging using \\\\.\\COM8\n"
~"Ignoring packet error, continuing...\n"
&"warning: unrecognized item \"timeout\" in \"qSupported\" response\n"
~"Ignoring packet error, continuing...\n"
~"Ignoring packet error, continuing...\n"
&"Bogus trace status reply from target: timeout\n"
^error,msg="Bogus trace status reply from target: timeout"
-target-disconnect
^error,msg="You can't do that when your target is `exec'"
-gdb-exit
^exit

What’s more, the ESP doesn’t run the code and when rebooted via a button it spits out this on the serial.

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x3ffe8000, len 916, room 16 
tail 4
chksum 0x9e
load 0x3ffe83a0, len 1084, room 4 
tail 8
chksum 0x3f
load 0x40100000, len 30828, room 0 
tail 12
chksum 0xab
csum 0xab
ŒâÜ[00]ìx[02]‚nÀä>[12]rÜØònãb[0C][18]’[0C][1C]žl`[1B]Äœ„’œÃ[02]„ØbŸ[03].... (<-3 lines of garbage)

 

I tried every suggestion in this older thread to no avail: https://sysprogs.com/w/forums/topic/esp8266_thing-failed-to-connect-to-the-gdb-stub/

I also tried the IoT HTTP server example code unmodified and it too fails to run.

Suspecting a broken chip I then tried making a short test Arduino program and flashing the binary but to my surprise this worked fine. A string that is printed out in a loop with some delay in between comes out clean in the terminal window.

At this point I am completely stumped. Nothing in my hardware or software config has changed and nothing in the code either. Just this single invocation of system_restore() (via a push button signal) and my whole project blows up. The most worrying thing is that the code flashed via VisualGDB doesn’t even run. To verify that the chip is running I’m using a 5 seconds interval timer which prints a short message (os_printf()) but as of today, this doesn’t happen anymore. If it was a baud rate issue I’d expect to see some garbage characters printed out periodically but instead I only have complete silence.

Any suggestions on what more I can do to find the cause of this problem would be highly appreciated.

• This topic was modified 6 years, 9 months ago by parsec67.
• This topic was modified 6 years, 9 months ago by support. Reason: formatting

[support]

Hi,

No problem, we can help you resolve this. However unfortunately we could not find any licenses associated with your account. Could you please let us know the email address associated with your license so we could link it to your account?

[parsec67]

Hi,

Sorry, using a different e-mail address on forums to reduce chance of password hacking. Email for VGDB license is <removed per user request>

[support]

Hi,

It looks like a mismatch between the gdb stub baud rate in your project settings and the actual baud rate used by the device. Please try several typical baud rates (e.g. 115200, 74880, etc); if none of them works, please  change your firmware to output the character ‘U’ (0x55 or 01010101, so it will look like a uniform clock signal) in a loop and use a logic analyzer to understand the actual baud rate (simply measure the period of the output signal). You can also try explicitly setting the UART period on your board before initializing the GDB stub.

[parsec67]

Hi,

I only have two baud rate options in project settings. Of these 74880 was working fine until today.

I’ll try analyzing the uart output speed but I cannot understand why this would change all of a sudden when it has worked reliably for several days (and still works with Arduino code flashed)?

Also could you please remove my email address in my previous post, thanks.

[parsec67]

Alright, using VGDB, building and uploading code that prints out 0x55h in a loop and I measure nothing on the scope. There doesn’t seem to be any output other than briefly after resetting.

Back to Arduino, tried the same thing and when baud rate is configured to 9600 I get 4.8 kHz, for 74880 baud I see 37.4kHz. So UART looks okay to me.

I tried flashing VGDB binaries from within Visual Studio and independently using ESP Download tool but the result is the same.

[support]

Hi,

Thanks for checking this. It is starting to look like the ESP8266 initialization data might have gotten corrupt. Please try setting the Debug Settings -> Additional FLASH resources to program -> Initialization Data file to <SysGCC>\esp8266\esp8266-bsp\RTOS-SDK\bin\esp_init_data_default.bin. This should force VisualGDB to program the initialization data as well.

If this doesn’t help, please try connecting to the COM port using a different baud rate and then resetting the board. The garbage after the “chksum 0xab” text might be a meaningful error message printed using a different baud rate, so connecting under that baud rate should show garbage instead of “checksum” messages followed by a meaningful error text.

[parsec67]

Another thing that popped up. After flashing Arduino code and then re-flashing VGDB code the ESP will go into a boot loop.

The reason seems to be esp_init_data_default.bin is never flashed/flashed to wrong address by VGDB. In my project settings I have the default option set in Debug settings->Additional flash resources to program, Initialization data file: $$SYS:BSP_ROOT$$/IoT-SDK/bin/esp_init_data_default.bin

I was under the impression that this would be flashed automatically to correct memory address based on flash size setting which is 2MB for this board?

 

EDIT: I got around this by flashing with ESP download tool. The problem remains, however.

• This reply was modified 6 years, 9 months ago by parsec67. Reason: additional clarification

[parsec67]

I call Bingo on this one!

Explicitly setting esp_init_data_default.bin to be flashed under “Additional flash resources…” fixed my problem. I now have serial communication working again.

Thanks for all your help!

[support]

Hi,

Thanks for pointing this out. It looks like a potential bug in our debug plugin. Would you mind sharing the address you used to load the configuration file? VisualGDB uses the addresses from this page, i.e. 2MB should load it at 0x1fc000.

[parsec67]

Hi,

Yes, this is the address I was using.

Cant’ tell if it wasn’t flashed at all or flashed to wrong address, the progress bar stops reporting after boot and user code is downloaded. The boot loop I had was exactly as described on your link, i.e. rf_cal[0] !=0x05,is 0xFF

 

[parsec67]

A slightly related followup question: Is there any way to just flash ESP from VisualGDB? That is, to bypass the “connecting to GDB stub” part?

[support]

Hi,

OK, we have double-checked this and it looks like our programming plugin indeed did not load the init data file correctly in some cases. We have fixed it in the R14 toolchain relesae available here: http://gnutoolchains.com/esp8266/

You can program the FLASH memory without debugging via Debug->Program Firmware without Debugging.

[parsec67]

Thanks for checking, I will give R14 toolchain a spin.

> You can program the FLASH memory without debugging via Debug->Program Firmware without Debugging.

Of course, it was there right in front of me all this time…

[parsec67]

Hi again,

Does the updated R14 toolchain in some circumstances automatically flash blank.bin in addition to esp_init_data_default.bin?

I’ve now moved over to an Adafruit Huzzah (4MB) and noticed that WiFi credentials that are saved at memory address 0x3FE000 will sometimes get erased after flashing. I have not been able to discern any pattern, sometimes this sector is left untouched after flashing while other times it will be modified.

[Author]

Posts