ESP8266 – failed to connect to GDB stub

Sysprogs forums Forums VisualGDB ESP8266 – failed to connect to GDB stub

Tagged: ,

This topic contains 15 replies, has 2 voices, and was last updated by  support 1 year, 7 months ago.

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #19978

    parsec67
    Participant

    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:

     

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

     

    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 1 year, 7 months ago by  parsec67.
    • This topic was modified 1 year, 7 months ago by  support. Reason: formatting
    #19980

    support
    Keymaster

    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?

    #19982

    parsec67
    Participant

    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>

    #19985

    support
    Keymaster

    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.

    #19987

    parsec67
    Participant

    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.

    #19988

    parsec67
    Participant

    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.

    #19989

    support
    Keymaster

    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.

    #19990

    parsec67
    Participant

    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 1 year, 7 months ago by  parsec67. Reason: additional clarification
    #19992

    parsec67
    Participant

    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!

    #19998

    support
    Keymaster

    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.

    #20003

    parsec67
    Participant

    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

     

    #20008

    parsec67
    Participant

    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?

    #20034

    support
    Keymaster

    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.

    #20038

    parsec67
    Participant

    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…

    #20047

    parsec67
    Participant

    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.

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.