Flawed SRST logic

[UweBonnes]

I think SRST handling has a flawed logic. SRST gets asserted as soon as the user enables it. Scanning happensunder reset, and for most if not all devices only the cortex core debug registers are accessible, but not the device specific registers indicating the device. So only the Cortex core will get detected, not the device. Only with attach, SRST is de-asserted. Probe should happen with SRST de-asserted.

[konsgn]

Are you also using the hw rev 2(2.1)? If so, the current code sets the reset line to open-drain, which the voltage translator may not understand. In my code I modified the code to set the line to push-pull as in the other issue post and that fixed the scanning under reset as it stopped keeping the chip in reset.

Of course, I still have issues erasing any chip, but hey, they do get detected fine now.

[UweBonnes]

No, it was other hardware. Your problem is different. Your problems does not touch the SRST logic, it is with regard to the SRST hardware.

[gsmcmullin]

At what point do you want to release the SRST signal?

The current behaviour seems to be sane to me. With the STM32 devices (which seem to be the problem case here), the DBGMCU_IDCODE can be read while in reset.

We should run tests with all supported devices and catalog what works and what doesn't.

Releasing SRST at the probe stage is problematic, because there may be multiple devices or cores that share a common reset. If we release SRST when the first is probed, we may have a problem probing the others.

[UweBonnes]

It seems, STM32L0 and STM32F7 are problematic. I will do more tests (empty device and programmed, running without and with WFI) and summarize. However I don't have JTAG access to those parts, only SWD. Maybe for SWD probe we can release SRST before probe. We probably don't support Multi-Drop SWD yet.

[UweBonnes]

L0 is SWD only, on a F7 Nucleo-144 I can probably wirr JTAG manually.

[UweBonnes]

20180622: Git head allows to release SRST before probe.