14:38 <gamiee> Well, I encountered an serious issue. My reset mechanism works in a way, that it triggers SW reset, which resets also pinmux. So JTAG is not available, until BootROM does not reconfigures it back. Everything works, if JTAG is fast (10 MHz clock). But when it's around 1.5 MHz, it's too slow, and it end ups too late, even in app, and does not halt the chip. Any ideas how I can improve this please?

16:58 <gamiee> another question... When the reset happens (no matter arch or chip), does OpenOCD tries to halt CPU right away or how this works?

17:09 <marex> depends on the configuration, reset / reset run / reset halt , and also on the hooks in tcl code

17:56 <borneoa___> gamiee: hi, I'm reviewing the comments on your patch. But what you say now is that the patch has some limitation. Do you know if the soc or the CPU offers some hooks to halt the CPU after a SW reset? That would be independent from the JTAG speed

18:00 <gamiee> borneoa___ : hi! Yes, unfortunately, it seems my patch relies on the fact that JTAG adapter is fast enough. On slower adapter, it fails. I found a way to avoid fail (not a hack), but the CPU is halted already in APP, not in BootROM, so making breakpoint on start of the user firmware is not possible to do.

18:00 <gamiee> And that's exactly what I am looking for. Unfortunately, (in simplicity) I found only way to delay BootROM until it launches the user firmware (might be useful, but so far not, need more exploration). I am now researching on JTAG level how whole reset works, and how the chip is communicating, to find some better way.

18:34 <gamiee> honestly, I am starting to be super frustrated, this is like 5th rewrite of the reset algorithm I am doing.

19:04 <gamiee> Fun fact is, that even flash driver is much more complex, that part worked so far flawlessly. (in opposite of reset mechanism)

19:24 <gamiee> I will try some other technics, although, not sure how long it might take :(