probe-rs icon indicating copy to clipboard operation
probe-rs copied to clipboard

Incorrect reset behaviour

Open jeriksson621 opened this issue 2 years ago • 6 comments

Describe the bug The reset line is not handled correctly. I have virified with a J-Link mini/educational and a ST-link from a nucloe F401re Target mcu ATSAME70N20B Majority of the time the reset line is held constantly low, i.e. holding the target in reset. A have gotten sporadic behaviour where the reset-line is high at boot, and then communication has worked. One instance the Jlink interface was even outputting a square wave signal on reset. Adding "--connect-under-reset" will in 100% if cases pull the line low and then it never returns to high,.

To Reproduce Steps to reproduce the behavior: Connect a Jlink of ST-link

measure voltage on reset, low in majority of cases, ~20% high, 5% square wave.

probe-rs erase --chip ATSAME70N20B doesnt work. (unless you are lucky and reset is high att boot)

run

probe-rs erase --chip ATSAME70N20B --connect-under-reset Fails 100% of times, holds reset low continiously

run

probe-rs erase --chip ATSAME70N20B now it fails 100% of times and reset is constantly low.

Expected behavior

probe-rs erase --chip ATSAME70N20B Should not pull reset

probe-rs erase --chip ATSAME70N20B --connect-under-reset Should cycle reset

Stacktrace N/A

Desktop (please complete the following information): Windows 11 host, Ubuntu 22.04 VM probe-pr downloaded through cargo yesterday.

Additional context Prefer to get "--connect-under-reset" working to mitigate soft-brick issues.

jeriksson621 avatar Sep 15 '23 14:09 jeriksson621

I am not really sure where this behavior is coming from, but did you make sure your reset pin is working as intended?

This feature was always working without troubles and was not touched in a while - to my knowledge at least.

Yatekii avatar Sep 16 '23 19:09 Yatekii

I have tested some more, there seems to be two things going on here, ATSAME70N20B seems to not enable communication while reset is asserted (low). Atleast not with my setup.

And there is a bug in probe-rs, that seems to be triggered when --connect-under-reset fails.

I have verified it with a nucleo-f401re board, while debugging the onboard f401re.

Steps to reproduce:

Disconnect one of the jumpers that connects the SWD, i.e. make sure the following command fails: probe-rs erase --chip STM32F401CBUx --connect-under-reset

If you now measure the reset line it will be held low by the ST-link hardware probe. reconnect the SWD jumper.

Call: probe-rs erase --chip STM32F401CBUx

This call will fail, but when returning it has released the reset line.

Call: "probe-rs erase --chip STM32F401CBUx" again, now it works since the previous call released the reset line.

i.e. The erronous behavoiur here seems to be three things:

  1. "probe-rs XXX --connect-under-reset" returns without releasing reset when it fails.
  2. "probe-rs erase --chip STM32F401CBUx" does not make sure that the probe is a correct state when initalizing (i.e. deasserting reset)
  3. SWD communication seems to fail when reset is asserted on the ATSAME70*

Do you have any idea of what to check to debug point 3?

jeriksson621 avatar Sep 18 '23 12:09 jeriksson621

Regarding point 3, are you sure that the chip supports debugging while the reset line is asserted? As far as I know, not all chips support this.

Tiwalun avatar Sep 18 '23 13:09 Tiwalun

yeah, also, I recall the atmel chips have some finicky reset routine that technically requires custom sequences but might work by sheer coincidence. afaik atmel chips support debugging under reset (at least in limited capacity) tho.

Yatekii avatar Sep 18 '23 16:09 Yatekii

If it is supported or not is not documented at all that I have found. This is definetly a likely reason for this issue. I believe the E5x series has some custom "reset extension", but the E70 should not have this issue atleast.

jeriksson621 avatar Sep 19 '23 13:09 jeriksson621

Neither the j-link, nor the st-link drivers in probe-rs are compatible with reset extension. Reset extension requires the probe to hold the TCK line low, which is implemented via calls to swj_pins, but the drivers only implement control of nRESET. It's unclear whether this can change in a meaningful way, but we may be able to work around it. cc #2325 that attempts something related.

bugadani avatar Mar 28 '24 23:03 bugadani