Make target reset functionality work out-of-the-box

[geekman]

There are multiple problems that prevent target reset functionality from working properly:

1. GP1 doesn't seem to work, haven't really dug into why.
   Moving to GP4 works, but this also means having to shift the UART to GP8/9.

2. gpio_set_dir() for the reset pin is opposite to what was intended:
   state = 0 means assert reset, but the current logic in probe_assert_reset passes state directly to gpio_set_dir, which when 0 actually means GPIO_IN. When the pin is an input state, it is pulled-up high, so reset is actually not assserted.

3. Reset pin also needs to be de-asserted in probe_deinit.
   Otherwise when a connection is first attempted and failed, nRESET will be stuck in an asserted state subsequently.

With multiple issues stacked together, target reset functionality could not be enabled easily by tweaking some #defines,
as evidenced by issue #120.

This PR should make target reset work properly now.

[lurch]

I'd be reluctant to move the UART pins as it'd make the wiring instructions in https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf invalid.

[geekman]

Understood. What pin should I assign it then? GP6?

[lurch]

That's a question that @P33M is probably better-placed to answer than I am.

[P33M]

GPIO6 is un-levelshifted uart RX input on the Debug Probe. Unfortunately only GPIO0 and 1 are the only unassigned pins broken out to somewhere accessible on that board. Why doesn't GPIO0 or 1 work as a reset output?

[geekman]

No idea, GP0/1 just doesn't respond to the code, it always stays high. When I change it to GP4 it works as expected (after all the other changes, of course).

[lurch]

I don't know how / when / where the "debug pins" are used, but I wonder if it might be clashing with DBG_PIN_WRITE ?

[xobs]

I've added some patches on top of the ones by @geekman. The big change is to move DAP_Setup() to come after stdio_uart_init(). The former muxes PROBE_PIN_RESET as a GPIO, and the last muxes GP0 and GP1 as a UART. If you select either of those as a reset pin, your choise will get overwritten.

I've also made a minor change in that I disable the pullup for the reset pin, under the assumption that the target already has a pull one way or the other.

The pull request there is https://github.com/geekman/debugprobe-dev/pull/1 and includes this nice screenshot of a reset working well from openocd using GP1 as the target:

It's possible there is still some interference going on if you use GP0, but overall I'm happy with this result.

[geekman]

Thanks for chasing this down. I've added your commits onto the PR.

[P33M]

Merged, thanks - ignore the spurious revert message.

[lurch]

So in hindsight, perhaps the problem was that the #define PROBE_PIN_RESET 1 in include/board_pico_config.h was conflicting with the #define PICO_DEFAULT_UART_RX_PIN 1 in https://github.com/raspberrypi/pico-sdk/blob/master/src/boards/include/boards/pico.h ?

@P33M Should there be a #define in debugprobe that can be used to (more easily) disable usage of stdio_uart ?