[reset] flashing: reliably flashing, loading and running code.

[rewolff]

To reliably flash, and run a new version of my program I need to:

• hit the hardware reset button on the board WHILE the processor is executing code (not stopped).
• type "load'
• type "continue".

I think it should be possible to reset the target from inside GDB.
I found somewhere:
monitor reset init
which does not do the trick.

While sometimes I see a flash error, I usually end up running an older version of the software.

What I want is that I press "control-C" in my gdb window, then reset, load, run the newly compiled code.

I have the impression that the "continue" will not restart at the reset vector, but in the middle of my now-different program (i.e. possibily crashing, usually I change the init code, so I SEE the old behaviour). The "monitor reset init" doesn't seem to help.

• Is this expected behaviour?
• Is it possible to reset the target? (I currently have "NRST" hooked up to the STLINK, but it has also worked without the NRST line hooked up.)
• What command should reset the target?

[rewolff]

OK. analysing the source...
monitor jtag_reset
in GDB seems to reset my target.

[rewolff]

OK. More research... :
http://gpio.kaltpost.de/?page_id=148
mentions "kill/y / load / run " Seems to work. (with a delay?)

[rewolff]

The links on the discovery and nucleo boards that disconnect the onboard stlink from the target do NOT interrupt the NRST line. so whenever you reset the non-onboard-cpu, the one on the board will also reset....

[xor-gate]

Old issue, please open a new one when tested with latest tools and firmware when still exists.

[Nightwalker-87]

@rewolff: What is the current state of this topic? Is there a correlation to issue 290 in terms of being delay-related?

[rewolff]

Two things. edit: correction: three things:

1. Issue flash loader run problem....  #290 is about the computer-side of things. When the CPU doesn't react as we expect it to, you can wait for a little while and try again. If after say 100ms the CPU still hasn't responded, you can bet your ass that it never will. That's how the code was written. But due to Linux and other Unix-like operating systems having to round small delays up to a multiple of a tick, when the CPU did NOT respond, the delay wasn't 0.1 seconds as intended but about 20. That issue is an "easy fix" (for me) as it only involves the linux-side of things. When things go wrong, simply program the error message to appear after 100ms as intended instead of after 20 seconds as happened in practice. That issue is resolved with my patch/pull.
2. Why do we occasionally get the "flash loader run error"? First: The "stlink" on the discovery and "nucleo" boards have a GPIO on the stlink STM32F10x connected to the reset of the target. So when you try to assert the reset from st-util or st-flash, that resets the CPU. This line is also brought out on the 6-pin SWD header. I and others have designed boards that use the pinout of this six-pin header to allow programming and debugging of other target boards. Just remove the two jumpers on the nucleo/discovery, and you have yourself a STLINKV2 programmer. When I started with STM32 the nucleo's could be bought for about EUR 10, and the STLINKV2 cost about EUR 50. So that was a cheap option. But nowadays you can buy STLINKV2 clones in china for even cheaper. Turns out someone hacked something and got hold of the firmware in the STLINKV2 and built a board that could run that firmware. Turns out that they reassigned the pin called "reset". When you ask the firmware to assert reset it will program say PB3 low, while on the clones it is PB4 that is connected to the header labeled "reset". (I don't remember the real pin names). I used to have one chinese clone patched to bring out the right pin, but now I have so many I don't know which one is patched....

So.... If you try to reset the CPU to make it stop interfering with your download, asserting the hardware reset line doesn't always work. As my STLINKs don't have the hardware reset hooked up, I've stopped using the wire from the stlink to the target.

2b: I think there should be a command through SWD that can halt the CPU. Somehow that didn't always work, or wasn't issued at all.

I think that the "flash loader run error" issues have been fixed. On the most recent version I've not seen them anymore. My suggestion is to just close all these issues and wait for it to happen again before we sink more time into this.

3. You "assign" issues to me. I get emails about that. What does that mean, what do you want me to do? I've submitted a pull request, and I think you accepted it. So for me that closes the issue. Do you want me to hit "close"?

[Nightwalker-87]

Thank you very much for the detailed explanation which is indeed very helpful.

As it reads, point 2) does seem hardware related. As I understand it this is related to a non-unified pinout between original STLink-v2 programmers and STLink-V2 clones regarding the Reset-Line.
So this may want a note in our documentation to advise users to check whether their Reset-Signal is addressed via the right pin, which is also used on the genuine boards (either stand-alone or as part of the evaluation kits). Though I haven't had a closer look, it is very likely that st-link tools currently use the "standard" GPIO dedicated for this by ST.

2b) should have a new, separate issue opened (if it does not exist yet) which solely addresses this feature request and nothing else.

[rewolff]

The reset line not being wired up can be considered a "hardware issue".

But it explains a few things. First of all, original developer may have had that reset line hooked up and "debugged until it worked". So that might explain why this stlink software "requires" it.
On the other hand, maybe the windows software does NOT use the hardware reset line. That would explain why the chinese clones were deemeed to "work" when they were missing the reset line....

The combination of these two means that we can improve stlink to the point that it no longer requires the hardware reset line to work properly every time.

I have retested the flash loader error. I can now reproduce it in v1.2.0, I can't compile v1.3.0 to v1.5.0 and v1.6.0 is fixed.

[Nightwalker-87]

Related to #220 & #356.

Summary:

1. Hardware-related timing issue upon connection (WAIT_ROUNDS) --> fixed in flash loader run problem....  #290
2. st-flash --reset in relation to the availability of a reset pin --> see [reset] st-flash --reset option doesn't work when reset pin is unconnected #220 + new section in our tutorial / documentation
3. Software reset for st-flash via the SWD interface without a reset line --> improvements & corrections in [feature] Extended support for STM32H7 & rework of software reset #1071
4. st-flash run_flash_loader(0x080000000) failed issue caused by an incorrect busy wait cycle --> fixed in Flash loader rework #1113