ESP8266 Community Forum

- Wed Mar 04, 2015 1:18 am #11238

Do you have any clues how software breakpoints like these interact with the IRAM caching?

This CPU core does not have cache, so there are no issues with that. If there were data or instruction cache, data cache needs to be flushed and after that instruction cache needs to be invalidated at the breakpoint address.

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?

It's not the processor-type cache, apparently the whole FLASH is cacheable, but there's no information about FLASH cache geometry. And I don't know of any way we can write there as if it was memory.

(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.)

Yes, and they do work. I believe it's the only way to debug ROM, and probably the only way for FLASH as well.

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?

I don't know of such requirement. MTDO pin is treated as a strap pin at reset, so it needs to be low in order to boot from UART or from FLASH. But the exact timing of latching straps is unknown. Hopefully it's latched right at reset release. With MTDO high at reset time it is known that ROM does not change GPIO MUX settings, so JTAG pins are functional. I guess at reset time JTAG pins must be functional as well, so MTDO is not relevant if you can catch ESP right at its reset vector.

- Wed Mar 04, 2015 5:15 am #11251

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?

It's not the processor-type cache, apparently the whole FLASH is cacheable, but there's no information about FLASH cache geometry. And I don't know of any way we can write there as if it was memory.

OK, thanks. This is the kind of caching I was trying to refer to (not CPU caching). The mention of setting software breakpoints in "IRAM" in the earlier post made me think that the flash might somehow be transparently mapped as a RAM-like region, beneath a cache layer, but this was obviously wishful thinking. Have done some more reading now about the various regions and what people have worked out.

I don't know of such requirement. MTDO pin is treated as a strap pin at reset, so it needs to be low in order to boot from UART or from FLASH. But the exact timing of latching straps is unknown. Hopefully it's latched right at reset release. With MTDO high at reset time it is known that ROM does not change GPIO MUX settings, so JTAG pins are functional. I guess at reset time JTAG pins must be functional as well, so MTDO is not relevant if you can catch ESP right at its reset vector.

Thanks for clarifying. I haven't found a method to halt into OCD mode at the reset vector yet, but I'll keep trying various combinations. Do you know if xt-ocd do this?

- Wed Mar 04, 2015 5:33 am #11252

I haven't found a method to halt into OCD mode at the reset vector yet, but I'll keep trying various combinations. Do you know if xt-ocd do this?

I don't: I haven't attached SRST at all, partly because I had ESP03, where RST is not broken out, partly because I couldn't find an easy way (besides fixing source and rebuilding) to configure xt-ocd to use ARM-USB-TINY-H reset line. It differs from that of the Flyswatter2, which xt-ocd does support.
I'll try to see if xt-ocd is able to do it.

- Wed Mar 04, 2015 8:25 am #11257 Just pushed some more commits, the problems with gdb losing sync seem to be gone - can step, halt, and continue over and over for a long time without anything breaking.

I realised gdb isn't producing valid disassembly in the 'layout asm' view. Shouldn't be hard to fix as 'xtensa-lx106-elf-objdump -d' produces valid disassembly. Have added this and other issues to the Issues list on github: https://github.com/projectgus/openocd/issues

Feel free to add anything else you find.