ESP8266 Community Forum

- Fri May 29, 2015 11:10 pm #18917

Sorry, I missed a detail somewhere and thought you were using JTAG of some kind. What are you doing? You're writing code that allows esp8266 to be a gdb server for itself, without using the OCD (on chip debug) features?

No.
Playing. Raw version of c/si/x/hbreak and ctrl-c sometimes running, not ready to publish yet,
Yes. Thats why I aked for a gdb server trace from you to see how gdb multi thread stuff is used on that single
thread bare metal. Would you, ...., please ?

Here you go: https://projectgus.com/files/esp8266/debugsession/

The files are a 'script' capture from gdb with 'debug remote 1' and an openocd log with '-d' set.

Order of operations was something like: connect to remote, mon reset halt, bt (got somewhat invalid looking trace - the register cache doesn't seem to refresh properly immediately after reset), si, bt (got better looking trace), info regs. Then tried 'continue' but something broke so reset, ctrl-c to break, bt, si a few times.

The program under test was compiled with the RTOS SDK.

Can do that but i got the impression that those interrupt numbers are the virtual interrupt numbers
as defined by xtos.
An incomplete list is here (the "interrupt related" numbers)
https://github.com/nodemcu/nodemcu-firm ... /ets_sys.h

That may be different for rtos.

Sounds like you might be right. Lots I don't quite understand about how it all fits together!

What timezone do you have? For me its MET (GMT +2, Europe, Germany).

Melbourne, Australia. GMT+10.

- Sat May 30, 2015 2:47 am #18924 Cool, thanks.

There is an"ir capture error" in your log that may indicate a problem in the esp8266 stuff on your gdbserver.
From shortly looking the stub seems to do minimal thread handling.
I have to go through it in detail, but up to now it looks that i have at least a 95% match when I ignore the
Ctag stuff. Promising.
Does RTOS have a thread model? Is that supported by gdb?

The registers where requested on each stop. The bt may be patially valid. Si makes "hops" for me, too because of interrupts
that then execute code on level 0. Can't understand how that works with stack or if I interpret findings wrong.
Looking at the stackpointer (a1) may give an indication of context.
I want to give the latest gdb from xtensa repo a try next.

bt:
I tried the same as your idea and just added a value to possible preamble end and it improved bt.
I wrote about it before.
Maybe good enough for now.
I was thinking about checking line numbers of not only the next instruction but the next instruction
after the block the next instruction is contained in but there are other places more important.

Lately I played with ccompare and dbreak and got them working.
I want to find out what keeps the watchdog from resetting the chip in normal operation
and try to find a way to break into gdb on or just before a wdt reset.
Or at least get some "post wdt reset" information about pc/stack bt after reboot.
Experiments of j* seem to indicate that iram/dram survive a reset so an early break into gdb after reset may help.

Cal

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Sat May 30, 2015 3:20 am #18931

There is an"ir capture error" in your log that may indicate a problem in the esp8266 stuff on your gdbserver.

The "ir capture error"s happen during reset. The JTAG hardware seems to come up quite slowly (~20-30ms after releasing RST) . Coupled with the fact that there's no IDCODE register or anything that makes it easy for openocd to identify a working JTAG tap, these errors get spat out as it tries to talk to the target.

By overriding the default openocd reset sequence you can suppress the errors, but this can be tricky too so I'm just living with them for now.

Does RTOS have a thread model? Is that supported by gdb?

It does. There is a way to make openocd/gdb aware of FreeRTOS TCBs, but I haven't yet tried to do this on esp8266.

The registers where requested on each stop.

Yes, gdb maintains its own cache of the CPU state which it refers to when interacting with gdb. Cache is invalidated/refreshed each halt. So when openocd uses CPU registers as scratch registers to read/write RAM, for example, gdb never sees the scratch register values. I'm guessing you must be doing something similar in your UART debugger.

The bt may be patially valid.

I realised I'd accidentally compiled an older version of gdb without the call0 backtrace patch, so I think that's why the bt looks weird.

There's also an openocd xtensa bug where registers aren't read from the target correctly following 'reset halt' (the hook that refreshes the register state doesn't fire), so that explains some of the invalid values.

Experiments of j* seem to indicate that iram/dram survive a reset so an early break into gdb after reset may help.

This is very interesting. I thought I tried this months ago and it didn't work. Maybe it depends on the reset type. Do you have a link to the discussion?


Angus

- Sat May 30, 2015 3:26 am #18934 viewtopic.php?f=13&t=3221

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG