Halting both cores makes espflash fail to reset the board with the USB-Serial-JTAG

[ProfFan]

Not very sure if this belongs here or espflash. The issue is simple. espflash can use the DTR signals to reset the board to flash mode before flashing. However in esp-backtrace we halt both cores on panic. After this flashing will fail until reset by the RESET pin. If I only halt CPU1 and make CPU0 do waiti 0 flashing works.

Wonder if this is expected?

[bjoernQ]

It's at least not very unexpected. Users currently could use the custom-halt feature to implement their own halt functionality. I could also imagine this to be a common enough case to have a ready to use feature in esp-backtrace

[bjoernQ]

I can reproduce it and the problem is halting core 0 (pro-cpu)
I currently don't see a way to stop core 0 from continuing when an exception/panic occurs on core 1 other than halting it

[MabezDev]

Btw @ProfFan, I'm guessing this only occurs with USB SERIAL JTAG? I imagine flashing via uart works as the reset is a physical toggle of the reset pin.

[ProfFan]

That's right @MabezDev, but somehow the official esptools.py can reset the board in some way while the espflash tool can't (need verification from @bjoernQ ).

I think this problem probably should not be part of the 0.20.0 milestone though.

[bjoernQ]

For me (on Windows, esptool 4.7) it cannot reset the board in that situation

[MabezDev]

I spent some time looking at this, it's not that trivial to solve. I'm not quite sure I see the value of halting the cores in the real world, it seems like most users would want to reset (with the option of breaking out to a debugger if it's connected), I think I'd rather prioritise time to that instead. I'll remove this from the milestone for now.

[MabezDev]

I don't see the value at all actually, I'll close this for now