Attempting to program a running CPU doesn't work.

[rewolff]

I sometimes have a batch of boards to program. Sometimes one of the programmed boards comes back to be programmed again. (maybe a newer version of the firmware, maybe by accident maybe...)

In that case, it often happens that flashing with st-flash fails.

I am guessing that this happens because the CPU is still running when we start to try to program it. So possibly the "flash loader" is written to RAM through the debug interface while my program is still running and modifying ram (as that's where the variables live). Then... either my program crashes (overwrite a return address on a stack and then this happens) or when the time comes to ask the CPU to execute the code in RAM the loader has been corrupted so the loader crashes.

In any case, retrying VERY often results in a working download/reflash. I'm guessing that by that time the CPU has crashed and there no longer is any interaction between the program and the loader-download.

I think it would be possible to halt the CPU before downloading the flasher code to RAM to prevent this from happening. As a workaround, a "verify" step of the loader downloaded to RAM could be added. This would then at least allow us to better diagnose what is actually going on. Or as an ugly workaround: you can retry the download, because by that time you've probably crashed the CPU already...

Oh... The code "halt the CPU, then download" is probably already there.. If that's the case, it is not working on F0. Then fixing that might help.

[Nightwalker-87]

@rewolff: To be able to solve this issue and help you along, it would be desireable, if you could provide additional info on your system and hardware.

[rewolff]

Nightwalker, keep up the good work. :-)

I am using a chinese stlink-2 clone dongle. The issue happens on all my boards, most noticable on a board that now uses an STM32F030C. (C=48 pins? If not, it is still the 48 pin version).

I don't notice it as much on my other boards: Those usually have STM32F072 CPUs and therefore USB and I program them using DFU.

[Nightwalker-87]

@rewolff: Thx for the update. I feel that there will be a solution, at least if this should technically correspond to the stlinkv2-clone dongle (which often use the CKS32F103), because I use one of these as well for programming bluepill boards. Will do some tests with these by mid of March, as I‘m currently on the move and without hardware. Will let you know by then.

[rewolff]

I'll be on the move in mid march too. Work abroad. But I'll take my hardware with me..... (I have to. The work requires it.).

[Nightwalker-87]

As this does not seem related to CKS32F103 there is also no need for testing related to this issue.

[cstratton]

I am using a chinese stlink-2 clone dongle.

Most of these do not have a functioning hardware reset output. Wherever the pin on the connector is wired to on the MCU comprising the adapter, it is not where the ripped off firmware thinks it is. Watch with a scope or analyzer and you'll see that no matter what host software does, the reset never changes.

As a result, anything needing an actual hardware reset in order to regain control of the target will not work.

[rewolff]

Well.... Because the retry works, the software could automatically retry the operation and simply work. First try crashes the running CPU, try again and it is no longer interfering with operations.
So here a retry would be useful.
On the other hand, st-util has a habit of retrying things when the USB system says: "Your device has disappeared, can't send it any commands". Those retries are bound to fail, there is no use in retrying in that case.

I fully agree with your statement about the hardware in the chinese STLINK clones. To prove your statement we once patched a chinese STLINK to make it work: We found the pin that the reset was on on the CPU and then patched that to the pin marked NRST. This was years ago.

[Nightwalker-87]

@rewolff Can you please test #1113 against this issue?
Please also summarize the singular problem(s) you faced here.
The history of this thread appears a bit confusing to understand currently. Thx.

[rewolff]

I can try to explain again...

For production programming (hundreds of boards, not thousands) I don't like to hit: "Now program this one".
So I have a script: try to program, if failed (no CPU): try again, if successful, play "ping" and try again.

Now sometimes a programmed board ends up with the unprogrammed ones. Or the firmware changed and the board needs an upgrade. Or we're slow in removing the connection between the programmer and the target after the "ping". So then the programming cycle starts again. You don't want to interrupt that because it might have wiped, and not yet rewritten half the code.

Anyway, when that happens you often see a failure the first attempt. Then on the second attempt the programming succeeds again.

[Nightwalker-87]

Anyway, when that happens you often see a failure the first attempt. Then on the second attempt the programming succeeds again.

@rewolff: Then please try the mentioned pull request by @Ant-ON , this issue was fixed there.
I ran into it before with my Bluepill board.

[Nightwalker-87]

As realised from the respective fork, the original author is currently working with v1.6.0 (commit f5d0454).

Using STLINK/V2 clone programmers is not a general problem - most do work reliable with the stlink toolset.
The missing ability for a hardware-reset due to the absence of a NRST line is compensated with a software-based JTAG reset functionality via the SWD interface. The latter has been improved with core halt in #1071.
The observed issue where only every second flash attempt succeeds is known to be fixed in #1113.

As there was no further response from the author, we must consider this issue to be fully addressed by the references above.
Against this background we may now safely close this ticket as resolved.