stlink behaves weirdly sometimes throughs tries Exceeded

[embhobbb]

i am using stlink clone with stm8s103 development board from quiet long time. But few days back my st-link got damage due short i think. so i am using new clone.
Now i am getting error as "Tries Exceeded" even though setup is same.
i am using Ubuntu 16.04 LTS.

i tried stlink with Windows STVP as well but there also no luck.

i tried with factory reset command as well but for flashing that binary also i am getting error as "Tries Exceeded"..```

echo "00" | xxd -r -p >ROP_CLEAR.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w ROP_CLEAR.bin

and also tried 

`stm8flash -c stlinkv2 -p stm8s003f3 -u`

Any help would be appreciated. 

[embhobbb]

Addition to above i could observe reset pin is going low when i start to flash. But pins keeps low after that. Might be missing response from PC tool.

[bWildered1]

Hi embhobbb

Just to eliminate ...

Are you providing power to the STM8 target from the STLink?

If so, could you try flashing while the power was supplied from another source?

M

[embhobbb]

i was providing the power from external source only. Now i tried with brand new stlink clone and i could able to flash the stm8s.
looks like problem with stlink. What could be the problem with stlink?
is there different variant in stlink clone as well?
i will check if i could make my previous stlink work with stm8s.

[prosper00]

I'm getting the same sorts of 'tries exceeded' problems. I have a couple STLink clones, and both are doing the same thing. Same results from at least 4 different computers. And I've tried powering the STM8 from the STLink and from an independent source as well. Basically, I've tried everything I can think of.

Occasionally - about once every 10 tries, I'll have a 'success' reported when I try to unlock the micro:
./stm8flash -c stlinkv2 -p stm8s103f3 -s opt -u Determine OPT area Due to its file extension (or lack thereof), "Workaround" is considered as RAW BINARY format! Unlocked device. Option bytes reset to default state. Bytes written: 11

...but usually it's
./stm8flash -c stlinkv2 -p stm8s103f3 -s opt -u Determine OPT area Due to its file extension (or lack thereof), "Workaround" is considered as RAW BINARY format! Tries exceeded

Any other operation fails with the 'tries exceeded' message.

I recently acquired a couple of those little fx2lafw logic analyzers, and I'm playing around with them to see if I can identify what's going on here. Attached is a Sigrok Pulseview capture of the SWIM conversation that happens with the 'successful' unlock attempt, and a capture of several failed attempts.

My analysis seems to indicate that the STLINK is often failing to send an 'ack' after receiving data from the micro (i.e. after a ROTF command). Then it times out, fires a 'nack,' and eventually repeats. I hazard a guess that this is a software problem (probably in the stlink firmware, but maybe with stm8flash). The hardware side does seems to be working, given the number of successful handshakes and mutual commands that are successfully getting handled in the capture files (such as the register WOTF commands that never seem to result in a NACK/retry). (BTW, the https://www.st.com/resource/en/user_manual/cd00173911-stm8-swim-communication-protocol-and-debug-module-stmicroelectronics.pdf document is an invaluable reference)

Anywy, I'm going to keep poking away at this - hopefully find a way to get stm8flash to work with flaky STLINKv2 clones - but I'd welcome input from someone who actually knows what they're doing :)

Captures of the RST and SWIM pins (you can open them with Pulseview, and use the delightful SWIM protocol decoder):
SWIM-cap.zip
swim-success.zip

[prosper00]

I downloaded the firmware update tool for my STLINK from ST, and tried a few different versions, with no changes. I don't see anything in the STM8flash source that I could obviously tweak, though I did do some debugging to watch the flow of the code.

I bought a new stlink clone, and it works great. It appears identical to my non-working STLINK - same pinouts, same silkscreen, same PCB. I'll do some captures from it, and see if I can figure out what's happening differently. However, given that identical firmwares from ST work on this device, but not my other device, I think its safe to rule out firmware as the problem. Must be a hardware difference, though, just what exactly is beyond me. It appears to be something timing related though, causing bitstream corruption somewhere on stlink itself, as my logic analyzer captures show appropriate data on the wire.

[dzid26]

I had similar issues after an unsuccessful flash with ebike controller (tsdz2). It always fails if a battery charger is connected - maybe due to noise, but i doubt. Anyway, this time it didnt want to flash again after the fail.
What helped was to power it up with reset tied to ground. Ithink. Then 1/10 times I was able to unlock the chip. But that didn't fix anything. Flashing continued to be unreliable. I think, controller power supply capacitors holding charge were adding to randomness. Because if I waited long enough, it was more likely for the flash to be successful.
It only after flashing actual firmware (which contained option bytes setup specific too the ebike firmware), the flashing became relaible like it used to.

Very strange

pulseview.zip