ESP8266 Community Forum

I've been working on adding esp8266 support to the openocd open source debugger program. Mostly this means adding Xtensa architecture support, or at least enough that esp8266 can work.

Progress is up on github: https://github.com/projectgus/openocd

Still very early days, not quite usable as a JTAG debugger yet but I think we will get there.

Current status:

• Can connect, halt, resume and single step instructions.
• Can read and write memory and registers.
• gdb kind of works - using the gdb built from the esp8266 crosstool-ng fork can attach, halt, step, view register state and assembly dump, etc. [s]>There's currently a bug that causes it to lose sync randomly after a short time and requires a reset. .[/s] EDIT: This bug is fixed, gdb seems stable now

Todos:

• Migrated to Issues List in github

Problems with no (yet) known solution:

• Also migrated to Issues List in github

Help wanted! Anyone who can help debug problems or finish things off is very welcome!!
(Note: at this stage un-detailed bug reports like "it doesn't work" aren't helpful, sorry, it doesn't work particularly well for anyone right now... )

JTAG Connections

I've only used an ESP-12 module as it has an exposed RESET line. I think it may be possible to use modules without exposed RESET, provided you don't configure those pins as GPIOs in your program(?)

• JTAG Signal -> ESP8266 GPIO Pin -> JTAG Pin (standard 20 pin connector)
• TMS -> 14 -> 7
• TDI -> 12 -> 5
• TCK -> 13 -> 9
• TDO -> 15 -> 13
• RST -> RST -> 15

[/list]

openocd command line
Something like:

Replace the first -f argument with the config file for your JTAG interface.

If you don't want to 'make install', you can run in-place like this:


Hope this is eventually useful for some people. . In particular I'm hoping this will be a tool to further understand the inner secret workings of the esp8266 hardware.

Hi, for setting the breakpoints, hopefully this code might help you.
CACHE_Ax(), WRITE_Ax, READ_Ax and EXEC_INSN() are dummy macros - shouldn't be a problem to replace them with your functionality, you already use all over the code.
Code is not compiled so consider it like a pseudo code. What it does is reading from the memory using L32i only as that's required for possible IRAM access. So, it might need 2 accesses in the case breakpoint address is not 4-byte aligned. Read data is stored in your BP table location i (here given as a simple pointer named saved_data). Then, the read out data is updated with the breakpoint and is written back to the memory - two S32i if needed.

About the 'reset halt':
If you enable OCD and issue Debug Interrupt while SRST is asserted, the core will enter halt mode as soon as you release SRST. For this to work, JTRST should not be touched.

uzevla wrote:Hi, for setting the breakpoints, hopefully this code might help you.

Thanks for this, definitely helpful! The 24-bit instructions with 32-bit word access really make for some gotchas.

Do you have any clues how software breakpoints like these interact with the IRAM caching? Does anyone know how the cache is mapped to flash, is it as simple as "the first 32kb of SPI flash is cached" or are there cache lines?

If there are cache lines, is there a chance breakpoints will vanish randomly as they get invalidated from the IRAM cache? In which case they'll need to be written to flash as well as IRAM. :/

(Even if software breakpoints have problems, the overlay indicates that lx106 has one hardware breakpoint address register and one watchpoint address register, so that's better than nothing.)

uzevla wrote:About the 'reset halt':
If you enable OCD and issue Debug Interrupt while SRST is asserted, the core will enter halt mode as soon as you release SRST. For this to work, JTRST should not be touched.

Excellent news! I'm a little confused though, do you mind explaining more?

My guess was that the reset pin on the esp8266 (EXT_RSTB in the datasheet, pin 32) is an SRST, that possibly also pulls TRST internally. I haven't had any luck getting JTAG to respond at all with this reset pin pulled low.

Someone on twitter (jcmvbkbc, also posts here) mentioned holding TDO high on reset to connect though, which seemed odd. Maybe this is required to connect under reset?