[freeck]

Hi Dan,

As suggested in one of the tutorials: put the be tested code in IRAM, then it works fine. Most of the hang-ups I experienced had to do with stepping out of your functions and entering systemfunctions. I delt with that by using the run-to-line debug command Or run to a next breakpoint.

[freeck]

Hi there,

I had the same experiences as you. I switched to the serial gdbstub-version which is well documented on this site. Its more stable, not perfect, but great to work with. Learn to live with the limitations…..
Advantage of using the serial port is that the jtag IO pins are free for your own application, although the panalty is that the serial port is occupied by the debugger.

Fred

[freeck]

This is part of the error log:
C:\SysGCC\esp8266/bin/xtensa-lx106-elf-gcc.exe -ggdb -ffunction-sections -O0 -nostdlib -mlongcalls -mtext-section-literals -nostdlib -mlongcalls -mtext-section-literals -I. -IC:\SysGCC\esp8266\esp8266-bsp/sysprogs/include -IC:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/include -IC:\SysGCC\esp8266\esp8266-bsp/RTOS-SDK/extra_include -IC:\SysGCC\esp8266\esp8266-bsp/GDBStub -DDEBUG=1 -DICACHE_FLASH -DESP8266_GDBSTUB -DGDBSTUB_BREAK_ON_INIT=1 -DGDBSTUB_FREERTOS=0 -c C:\SysGCC\esp8266\esp8266-bsp/sysprogs/stubs.c -o Debug/stubs.o -MD -MF Debug/stubs.dep
1> C:\SysGCC\esp8266/bin/xtensa-lx106-elf-g++.exe -ggdb -ffunction-sections -fno-exceptions -fno-rtti -O0 -nostdlib -mlongcalls -mtext-section-literals -nostdlib -mlongcalls -mtext-section-literals -I. -IC:\SysGCC\esp8266\esp8266-bsp/sysprogs/include -IC:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/include -IC:\SysGCC\esp8266\esp8266-bsp/RTOS-SDK/extra_include -IC:\SysGCC\esp8266\esp8266-bsp/GDBStub -DDEBUG=1 -DICACHE_FLASH -DESP8266_GDBSTUB -DGDBSTUB_BREAK_ON_INIT=1 -DGDBSTUB_FREERTOS=0 -c LEDBlink.cpp -o Debug/LEDBlink.o -MD -MF Debug/LEDBlink.dep
1> C:\SysGCC\esp8266/bin/xtensa-lx106-elf-gcc.exe -ggdb -ffunction-sections -O0 -nostdlib -mlongcalls -mtext-section-literals -nostdlib -mlongcalls -mtext-section-literals -I. -IC:\SysGCC\esp8266\esp8266-bsp/sysprogs/include -IC:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/include -IC:\SysGCC\esp8266\esp8266-bsp/RTOS-SDK/extra_include -IC:\SysGCC\esp8266\esp8266-bsp/GDBStub -DDEBUG=1 -DICACHE_FLASH -DESP8266_GDBSTUB -DGDBSTUB_BREAK_ON_INIT=1 -DGDBSTUB_FREERTOS=0 -nostdlib -mlongcalls -mtext-section-literals -nostdlib -mlongcalls -mtext-section-literals -DDEBUG=1 -DICACHE_FLASH -DESP8266_GDBSTUB -DGDBSTUB_BREAK_ON_INIT=1 -DGDBSTUB_FREERTOS=0 -c C:\SysGCC\esp8266\esp8266-bsp/GDBStub/gdbstub-entry.S -o Debug/gdbstub-entry.o -MD -MF Debug/gdbstub-entry.dep
1> C:\SysGCC\esp8266/bin/xtensa-lx106-elf-g++.exe -o Debug/GpioTesten.elf -Wl,-gc-sections -Wl,-Map=fred.map -TC:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/ld/eagle.app.v6.ld -nostdlib -mlongcalls -mtext-section-literals -nostdlib -mlongcalls -mtext-section-literals -LC:\SysGCC\esp8266/hal -LC:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/lib -LC:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/ld -Wl,–start-group Debug/gdbstub.o Debug/stubs.o Debug/LEDBlink.o Debug/gdbstub-entry.o -lc -lgcc -lphy -lpp -lnet80211 -llwip -lwpa -lmain -ljson -lupgrade -lssl -lpwm -lsmartconfig -lcrypto -Wl,–end-group
1> c:/sysgcc/esp8266/bin/../lib/gcc/xtensa-lx106-elf/5.2.0\libgcc.a(_divdi3.o): In function `__udivmoddi4′:
1> /q/gnu/auto/gcc-bu-2.24+gcc-5.2.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2+newlib-2.0.0-xtensa-lx106-elf/xtensa-lx106-elf/libgcc/../../../gcc-5.2.0/libgcc/libgcc2.c:1078:(.irom0.text+0x8a): dangerous relocation: l32r: literal target out of range (try using text-section-literals): .literal
1> /q/gnu/auto/gcc-bu-2.24+gcc-5.2.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2+newlib-2.0.0-xtensa-lx106-elf/xtensa-lx106-elf/libgcc/../../../gcc-5.2.0/libgcc/libgcc2.c:1078:(.irom0.text+0x9a): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.literal+0x4)
1> /q/gnu/auto/gcc-bu-2.24+gcc-5.2.0+gmp-5.1.3+mpfr-3.1.2+mpc-1.0.2+newlib-2.0.0-xtensa-lx106-elf/xtensa-lx106-elf/libgcc/../../../gcc-5.2.0/libgcc/libgcc2.c:1078:(.irom0.text+0xd4): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.literal+0x8)
1> /

But strangely enough, when I deleted all 4 functions from libgcc.a the linker did no protest for these missing functions, so why were these functions included in the first place? After deleting all functions of libgcc2.c as displayed in the memory explorer I save ca 2K of IRAM, and the application is running OK…
I dont get this….

• This reply was modified 8 years, 1 month ago by freeck.

[freeck]

That was exactly what I did, but could not find any reference to udivmoddi4.
I repeated this procedure using the BlinkLed example, same result. perhaps you are able to find the reference?

[freeck]

Thanks for the advise.
Following your procedure I got the message from the linker that the calling function “__udivmoddi4” could not “reach” the relocated functions. So then I tried to relocate function “__udivmoddi4”, but there was no reference to “__udivmoddi4” in the map-file to be found…

[freeck]

Hi there,

It worked perfectly well with the ets_timer function. Unfortunately I ran into trouble trying function _divdi3.o, part of libgcc.a. A “dangerous relocation” error occured. It was suggested to add -mlongcalls to the compiler options, but no succes. Perhaps someone can give me a hint.
But perhaps better questions would be:
1: which know IRAM-functions can be relocated to flash? Perhaps there a list available?
2: Why did you select ets_timer as an example?

[freeck]

thanks, I continue with my experiences on that thread.

[freeck]

Humm… “boot mode:(1,6)” should work as well, as the ‘1’ corresponds to flash download mode….
As flashing worked well with another flashtool, it seems not to be an hardware issue.. I my case powering down/up the device sometimes worked, but I assume you have already tried these obvious things :).

Perhaps Sysprogs has any thoughts?

[freeck]

After pressing reset & flash what is the response of te target?
Should be: “ets Jan 8 2013,rst cause:2, boot mode:(1,7)”

If not the target was probably in a different mode. I got the same response as you did when I was stuck in a previous debugsession.

[freeck]

Hi, first time you downloaded new firmware? If so, did you ground GPIO15 as well?

• This reply was modified 8 years, 12 months ago by freeck.

[freeck]

Please double-check the settings in debug.mak and see if they are actually included in compilation command line.

Yes they are, but: I observe that the macro settings of esp8266.mak overrule the settings of debug.mak. Changing GDBSTUB_BREAK_ON_INIT in debug.mak has no effect. I think macro GDBSTUB_BREAK_ON_INIT=1 should not be included in esp8266.mak for any new project….but in debug.mak, not?

• This reply was modified 9 years ago by freeck.

[freeck]

Hi there,

PROBLEM SOLVED

You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program, from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

I modified the preprocessor-macro in file esp8266.mak itself, only then the gdb-stub break_on is disabled. So the preprocessor-macro in VisualGDB “Project Property->MakefileSettings” were not propagated to esp8266.mak !

• This reply was modified 9 years ago by freeck.

[freeck]

I think you were right stating:

If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect.

When I download the code using the esptool the code is also not running….But a gdb-stub status message appears via the serial interface! So in case you use gdbstub is will indeed hold up the application. So the question remains how to build an image without the gdbstub-stuff?  You stated: You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

I hope I did put the define on the right place in the makefile, but I observe that the gdb-stuf is always included in the image..also in case I build a non-gbdstub example application.
It remains a mystery to me why the jtag-debugging is also held up by gdbstub…

• This reply was modified 9 years ago by freeck.
• This reply was modified 9 years ago by freeck.
• This reply was modified 9 years ago by freeck.
• This reply was modified 9 years ago by freeck.

[freeck]

If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect.

You mean that a background process has already started before calling gbdstub_init()? If not: this does not explain why I could not reach a breakpoint in user_init()….and: In case I define a project example without gdbstub the application also does not start…..

I response to your questions:

-Using break all ( not “in”): The call stack shows some assembly instructions , no names of functions.

I observe a break at address: 0x40002eee

 

– Setting GDBSTUB_BREAK_ON_INIT=0 had no effect

– Commenting out gdb_init() had no effect.

 

 

[freeck]

<b>Led-blink example (ram):</b>

I observe that using jtag- or gdbstub-debugging using RAM-only works flawlessly. So no driver and connection issues. Breakpoint and single stepping function works OK. LED blinks.

<b>http-server example or ledblink (flash versions):</b>

Using gdb-stub downloading went OK, I could set a breakpoint and continue execution. I saw the wifi station in the air or the LED blink.  So the application seems to run. Strangly enough after a reset the application is not running, or not flashed, or not started…..(part of the problem?)

Using the jtag device: FLASH-downloading seems to go OK , no error messages in the gdb-window. However the breakpoint is never reached, and I observe no wifi-activity, nor the LED blink. So obviously the programmes have not started.

Changing reset mode and dis- and connecting the reset pin had no effect.

 

[Author]

Posts