[reset] st-flash --reset option doesn't work when reset pin is unconnected

[sinosoidal]

I'm using stlink to program STM32F4 family chips using the STM32F4 Discovery board. I need to program several three programs intro flash for my device to be completely up and running (bootloader, dfu, app). I use st-flash --reset write FILE ADDRESS and it appears that after each flash programming the reset option doesn't do anything. The behaviour is very inconsistent with the procedure. However, if I manually press the reset button on the board after each flash operation, everything goes perfect. I'm wondering if this is a know issue or if there any gotcha i'm missing here. Thanks in advance! Regards

[technobly]

I'm also looking for a way to use st-flash to reset and reflash my target without manual interaction. Is this possible? The ST-Link V2 can do this with STM32 ST-Link Utility software, so I'm assuming it's possible to do with st-flash as well, but maybe not supported?

[xor-gate]

Need to see if we need this patches:

aqwerf@c0a5be2
trainman419@4819eaa

Some people from STM32Arduino seem also to have some problems with reset (tested by @ekawahyu):
http://www.stm32duino.com/viewtopic.php?f=3&t=1012&p=13690

[rewolff]

A comment in the code (line 346 of usb.c) says:
* TODO - not convinced this does anything...
and I tend to be "not convinced" either..... (as in I have a suspicion that it "does nothing"... )

The --reset in the st-flash command line will issue both a jtag-reset as well as a "normal" reset. The jtag reset will work on the discovery boards as the jtag reset line is connected to the target processor.

That connection might be absent if you're using a cheap STLINK module (they have a different pin of the embedded STM32F103 broken out as jtag-reset, but not a changed firmware) or when you have your own hardware and didn't hook that up.

[girtsf]

I'm using a cheap STLINK module as well, and was running into the same issue of not being able to reset the board.

Here's a hacky fix that seems to work:

diff --git a/src/common.c b/src/common.c
index ebc1f8e..448c83d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -628,6 +628,9 @@ int stlink_load_device_params(stlink_t *sl) {

 int stlink_reset(stlink_t *sl) {
     DLOG("*** stlink_reset ***\n");
+
+    // Write SYSRESETREQ to NVIC AIRCR.
+    stlink_write_debug32(sl, 0xE000ED0C, (0x5FA << 16) | (1 << 2));
     return sl->backend->reset(sl);
 }

[xor-gate]

Probably fixed by hard-resetting chip using reset pin merged with PR #430. Feel free to reopen a new issue if the problem stil remains.

[rewolff]

The hardware reset line is not always connected. This happens when the SWD connector is minimal (only 4 pins: VCC SWCLK GND SWDATA) or when using a low-cost STLINK clone. That is why @girtsf 's fix is important.

The jtag reset was "reachable", already. for programming a chip (#430), I use a gdb-macro that issues the reset before attempting to do the programming. No st-util change necessary.

[Nightwalker-87]

@sinosoidal @technobly Does this work for you with the fix by @girtsf ?

[technobly]

@Nightwalker-87 I checked out the latest and compiled on Mac 12.14.6. It seems to reset a device and flash it without any changes. I've also added @girtsf 's change and see no difference. I'm using a Particle Photon with the ST-Link V2. The Photon uses a STM32F205RGY6 and I have an application running that turns PA13 (JTAG_TMS/SWD_SWDIO) into an output and is toggling it. Typically this would prevent SWD from flashing the device and require a reset for ST-Link V2 to connect to the target. The commands I tried and NRST line scope waveforms are as follows:

Without --reset

stlink/build/Release/bin $ ./st-flash write ~/releases/2.0.0/photon/release/photon-system-part1@2.0.0.bin 0x8020000

With --reset

stlink/build/Release/bin $ ./st-flash --reset write ~/releases/2.0.0/photon/release/photon-system-part1@2.0.0.bin 0x8020000

As you can see, without --reset actually seems better, cleaner? I don't know what was changed, but it seems to work now just fine with a real ST-Link V2 with both options. FWIW, I tried the $2 USB stick ST-Link V2 version and it doesn't seem to work at all for some reason.

EDIT: Something to note though, I had the NRST line connected. I'll disconnect it and report back.

[technobly]

With NRST disconnected, I'm not able to flash the device when PA13 is toggling. But if I put my device in DFU mode, that pin is left in the default state with all JTAG pins available, and both with --reset and without --reset I'm able to flash the device. It also works the same with and without @girtsf 's changes.

I should note that after flashing this way, it still requires me to hard reset the device to get it back in a running state. This might be due to the PA13 being set to an output, or it might just be that the JTAG reset is not really working.

[Nightwalker-87]

Thank you very much for the detailed feedback and also the helpful oscilloscope snapshots.

As you can see, without --reset actually seems better, cleaner? I don't know what was changed, but it seems to work now just fine with a real ST-Link V2 with both options.

I don't know either, but to be honest - I assume it is not even clear in general what is happening at this point.
What I got to know so far from my ticket review from all remaining open issues is that several people tried to fix it obviously without any proper unified approach. So what we have now is likely a mix of several patches an additions that does "something".
It is not clear yet if "something" is anything reasonable or solely holds some elements that make it work for most cases.

With this in mind and a view to several related tickets one would wish for a complete rewrite of this part of the code, I shall think.

[Nightwalker-87]

Related to #238.

[Ant-ON]

@Nightwalker-87 I was rewriting the reset work when fixing problems with H7. Changes from @girtsf are no longer needed.
@technobly Based on the description, everything works as it should. There is no way to reset without the NRST and PA13 pins. The reset is done by software when the NRST is not connected. For this PA13 must be configured as SWD_SWDIO/JTAG_TMS.
I don't know for what purpose --reset adds an extra reset when connected. It arg also should allows you to reset the MCU after flashing.

[technobly]

@Ant-ON I just confirmed when PA13 is not configured as an output, with NRST disconnected, everything works fine with and without --reset, and without any changes to the current repo. The device resets afterwards as well. So for my original issue 6 years ago, I'm guessing the NRST pin wasn't working correctly. Glad to see it's resolved ;-)

[Nightwalker-87]

@Ant-ON: Can you document the routine step by step, not only with comments in the code but also for our tutorial?

[Nightwalker-87]

@Ant-ON @technobly Can we also add the findings on the signal level to the tutorial (open PR) to have a more complete coverage on the difference? Would this be fine for you @technobly ?

[Ant-ON]

@Nightwalker-87 I don't see any need for them in documentation. They show a reset before and after flashing. And also there have reset needle, the reasons for which are not clear

[Nightwalker-87]

However, as seen from my perspective, this still wants some additional documentation on the hardware-side.
I'll preserve some useful info from this thread in our tutorial to explain the reset pin issue.

[Nightwalker-87]

Related to #774.