projectgus wrote: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.
projectgus wrote: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.
projectgus wrote:(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.
projectgus wrote: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.