odd behavior with debugging on V5.2 and esp8266

[krhodes@netboxsc.com]

I am using  the gdbstub with an ESP8266 over serial. I’ve been running V5.1 and has been working reasonably well.

Ever since upgrading to V5.2, when debugging and trying to “step over” (F10) it always is doing a “step into” (F11). I thought that maybe the subroutine was being inlined, but it did the same thing for a call to strlen(), which can’t possibly be inlined.

I tried enabling gdb logs in the Debug menu, but nothing is written to the log I specified.

Any thoughts?

One additional issue I had was when I had a breakpoint set in a function set with ICACHE_FLASH_ATTR, the entire system would not operate. It wouldn’t hit any breakpoints in my RAM, it wouldn’t start advertising as an AP, but the gdbstub seemed to be communicating. In V5.1, I could at least hit the breakpoint and not be able to single step after that.

Thanks…Keith

[support]

Hi,

This could be caused by VisualGDB setting some implicit breakpoints and using the one and only hardware breakpoint of ESP8266. Could you check this by entering the ‘info breakpoints’ command in the GDB session window and seeing if there are any breakpoints not explicitly set by you? If yes, does deleting them via the ‘delete’ command help?

[krhodes@netboxsc.com]

There wasn’t anything listed that I didn’t set, but I did find that the function that I set a breakpoint in was in ROM, not RAM. I am using the ICACHE_FLASH_ATTR macro to put functions into ROM and I didn’t specify  the macro for this function.

My compile flags are:

-ggdb -ffunction-sections -O0  -nostdlib -mlongcalls -mtext-section-literals -nostdlib -mlongcalls -mtext-section-literals  -DDEBUG=1 -D__ets__ -DGDBSTUB_REDIRECT_CONSOLE_OUTPUT=1 -DICACHE_FLASH -DESP8266_GDBSTUB -DGDBSTUB_BREAK_ON_INIT=1 -DGDBSTUB_FREERTOS=0

Is there another way to control the placement into RAM?

Thanks..Keith

[krhodes@netboxsc.com]

I found my problem. The function declaration in the source file didn’t have the ICACHE_FLASH_ATTR macro, but the prototype definition in the header file did (and the header was included in the c file).

The prototype in the header must’ve caused the compiler to put it into ROM. What is strange (and I’d submit is a bug) is that no warning was generated when the two differed. This will make it a bit of a challenge to ensure that the function prototypes match, as I will be moving functions between ROM and RAM a great deal.

…Keith

[support]

Hi,

Sorry, generating warnings in this case would require modifying the compiler, and we would rather not risk breaking things with that. The only workaround we could suggest is to quickly use the Memory Explorer window to double-check the sections for specific functions of interest.

[Author]

Posts