stm8s103f3 flashing - Tries exceed - Protected chip

[EvgenyAgafonchikov]

./stm8flash -c stlinkv2 -p stm8s103?3 -w ../sdcc-examples-stm8/blinky.ihx

results into

Determine FLASH area
Writing Intel hex file 194 bytes at 0x8000... Tries exceeded

There is stm8s103f3 controller on the "minimal system board". Can I help (e.g. providing of additional logs, testing) to make this toolset work with the controller mentioned?

Also, is there any native Linux way to flash stm8 as a temporary solution?

Hardware is similar to the listed in this article

[EvgenyAgafonchikov]

I tried to flash the same chip from Windows ST Visual Programmer and got "Device is protected" message. Removing of protection resolved the issue. Flashing is OK now from Windows and Linux both. Is it possible to add chip protection removal to stm8flash?

[arselzer]

Having the same problem with the stm8s103f3. Is there any way to "unprotect" the thing on Linux? Sadly I don't have any experience with STM8 microcontrollers, and would just like to experiment with them, so all I can do is +1 the issue.

[ghost]

read the manual and datasheet before ask, pls.

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

[arselzer]

@kensenjiha thanks. I've tried your solution on two boards, but it does not appear to solve the issue.

I still get the same error. Also, if that is relevant, the red LED (might be specific to the model I bought) stopped blinking when it is powered on:

stm8flash -c stlinkv2 -p stm8s103f3 -w blinky.ihx

Determine FLASH area
Writing Intel hex file 178 bytes at 0x8000... Tries exceeded

read the manual and datasheet before ask

No idea where to start, the 100 page PDF is for sure intimidating to me, and I would just like to get the 10 1$ microcontrollers from China working without having to use a crappy OS called Windows and a proprietary program :)

[merbanan]

I tried tinkering with a HC-11 board with a stm8s003f3 mcu. The ROP_CLEAR.bin file completed once but not again.

Determine OPT area Writing binary file 1 bytes at 0x4800... OK Bytes written: 1

And all other commands end up in the following:

Determine OPT area Writing binary file 1 bytes at 0x4800... Tries exceeded

[merbanan]

I tried ST Visual programmer and that worked fine. So I tried with increasing the duration of the TRY macro. This helps somewhat, I can read/write 50% of the times. With the windows software I get 100%, so something is wrong with the commands or timing.

diff --git a/try.h b/try.h index f584cf1..a077f6a 100644 --- a/try.h +++ b/try.h @@ -1,7 +1,7 @@

define TRY(times, statement) do { \

• int c = (times); \
• int c = (times*10); \ while(c > 0) { \
• usleep(3000); \
• usleep(10000); \ if((statement)) break; \ c--; \ } \

[minobull]

@AlexanderSelzer , try reset to factory defaults:

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

[arselzer]

@minobull Now it works, I was able to write to flash now. Thank you.

Also, if anyone has the same issue, the sdcc-examples-stm8 blinky.c example does not work on the stm8s103f3 boards. Use one from there instead: http://www.cnx-software.com/2015/04/13/how-to-program-stm8s-1-board-in-linux/

[hraftery]

@minobull that is sensational. After 5 hours working on this, your two-liner has turned a dead end into a success.

I guess the opt2 box in README.md can be changed to OK for stm8s103f3.

Very pleased to report success with OS X (El Capitan) + ST-Link V2 (Mini emulator on eBay) + sdcc + stm8flash + STM8S103F3P6 (minimum system development board on eBay).

Have attached a minimum blinky.c and a minimum Makefile to any others working along the same path. Just cut out the .txt extensions.

blinky.c.txt Makefile.txt

[blahlt]

It works also on Win7 x64+ ST-Link V2 + SDCC + STM8S103F3P6 I'd problem with error "Writing Intel hex file xxx bytes at 0x8000... Tries exceeded" and solution with factory_defaults.bin and ROP_CLEAR.bin didn't help to me. So, I installed "ST Visual Develop", have rewritten data in OPTION BYTE tab and my STM8S103F3P6 alive now.

I create options backup without ROP and now you can unlock your STM8S103F3P6 with command: stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w optdefault.bin

optdefault.bin.txt

[wonbinbk]

@minobull Thank god I found you!

Crazy... Yeah I didn't read manual or datasheet. I just wanted to confirm that my toolchain was working. That's why I follow tutorial online. How would I know that the chip has been altered from factory defaults. Never happen before. You sir, have saved my day. Below is my blinky version with sine wave emulating breathing on the LED (don't know what to call it but I think it's cool to look at). blinky.c.txt

[bWildered1]

Hi. I have encountered a similar, but not identical, problem with an STM8 L 151K4 device.

stm8flash 20170616-1.1 Ubuntu 16.04.1 64-bit

Initial attempt to flash this device reported 'Determine FLASH area Writing Intel hex file 217 bytes at 0x8000... Tries exceeded'

Testing with STVP on Windows indicated that the device was read out protected. Cleared read out protection, using STVP. Note: On this device, read out protection seems to be disabled when first option byte is set to a value of AA. This seems to be the opposite of some other devices in the STM8 series.

Could now flash device on Windows using STVP. But still cannot flash device on Ubuntu using stm8flash, getting same report (Tries exceeded) as earlier.

However, can read both flash and option bytes using stm8flash on Ubuntu machine.

stm8l151k4_opt.txt

Am probably doing something silly.

Should I have posted this a a separate (new) issue?

I have attached the result of the stm8flash option byte read, although this file had to be renamed with a .txt extension to be uploaded.

Take care.

M

[dj0abr]

the issue with "tries...exceeded" has nothing to do with a protected chip or similar. It is a timing issue of stm8flash. If i run stm8flash in a loop, then sometimes it works, and most of the time does not work. Maybe depends on the speed of the PC ?

[alekratz]

I am having "tries exceeded" happen on my STM8s103f3 chip when trying to reset to factory defaults. I have not run it in a loop to see if I can get one try to work, but I will overnight and see if it works.

[alekratz]

Did not work. Anyone who finds a solution, please ping me - I would like to get my boards working :)

[alekratz]

Update: I got a new ST-Linkv2 in the mail and I tried that with my STM8 boards - two out of three worked on the first try with the new link. The third one is being a problem child, and I get this feeling I may have messed something up with it in the process of trying to get it to flash. I used the -d slow option, I'm not sure if that helped. If you want some sort of diagnostics about where tries exceeded, change line 6 in error.h to read like this:

#define ERROR(s) do { fprintf(stderr, "%s in %s:%d\n", (s), __FILE__, __LINE__); exit(-1); } while(0)

This will tell you the source file and line that actually ended up failing.

Honestly, I think these are the results of cheap hardware and good/bad luck. Keep trying, and if you have the money to buy another STM8 or ST-linkv2, it might fix any problems you have with the flash. It's disappointing, I understand, but that's the price you pay for cheap hardware. Good luck and godspeed the rest of you reading this.

[bWildered1]

A little while back, I noticed that the success or failure to upload code to STM8 devices depended upon which USB port I used.

I assumed, rightly or wrongly, that some ports were not able to supply adequate current.

I have not done enough experiments on this to either confirm or disprove though.

M

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free. www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On 31 March 2018 at 18:25, Alek Ratzloff notifications@github.com wrote:

Update: I got a new ST-Linkv2 in the mail and I tried that with my STM8 boards - two out of three worked on the first try with the new link. The third one is being a problem child, and I get this feeling I may have messed something up with it in the process of trying to get it to flash. I used the -d slow option, I'm not sure if that helped. If you want some sort of diagnostics about where tries exceeded, change line 6 in error.h to read like this:

define ERROR(s) do { fprintf(stderr, "%s in %s:%d\n", (s), FILE, LINE); exit(-1); } while(0)

This will tell you the source file and line that actually ended up failing.

Honestly, I think these are the results of cheap hardware and good/bad luck. Keep trying, and if you have the money to buy another STM8 or ST-linkv2, it might fix any problems you have with the flash. It's disappointing, I understand, but that's the price you pay for cheap hardware. Good luck and godspeed the rest of you reading this.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vdudouyt/stm8flash/issues/38#issuecomment-377709333, or mute the thread https://github.com/notifications/unsubscribe-auth/AcmEmQuphUyJG4U3UEgVv5C3a49sfsieks5tj7v6gaJpZM4HNrmR .

[embhobbb]

I am also facing the same issue on Linux.

Is anyone got any solution on linux yet?

[embhobbb]

Is there any solution got for this issue yet?

I am also facing same problem.. 1811 bytes at 0x8000... Tries exceeded.

[bgrumbine]

This issue probably ought to be closed.

@embhobbb yes, there were multiple solutions given.

If you are in fact getting "Tries exceeded" due to a protected chip (ROP flag), one of the solutions provided by @ghost, @minobull, or @blahlt should have worked for you.

I'm using OpenBSD and had to install vim(1) to get the xxd(1) command.

You may very well be experiencing ST-Linkv2 issues like @alekratz, but that is outside the scope of this issue.

The dev boards I ordered already had blinky running, so I suspect the ROP flag got set when they flashed blinky.

Personally, I skipped the @ghost solution, went straight for @minobull, and was then able to flash my own program.

Lastly, @wonbinbk thanks for that blinky.c with the sine wave, that is kind of cool. I made a couple of changes so it doesn't need: #include "stm8-header/stm8s.h"

--- blinky.c.orig       Sun Sep 29 23:16:29 2019
+++ sinusoidal_blinky.c Sun Sep 29 23:19:26 2019
@@ -1,4 +1,9 @@
-#include "stm8-header/stm8s.h"
+#include <stdint.h>
+
+#define PB_ODR          (*(volatile uint8_t *)0x5005)
+#define PB_DDR          (*(volatile uint8_t *)0x5007)
+#define PB_CR1          (*(volatile uint8_t *)0x5008)
+
 #define period 1000
 int sine[102]={ //sine(pi/100) * 1000

[dangrie158]

Just ran into this issue and as it turn out on my ST-Link v2 clone the SWIM and GND Pins were swapped on the silkscreend label on the programmer. swapping the connections did fix the issue

[embhobbb]

@bgrumbine i had working stlink previously. i have created another thread and here is the link. STLINK behaves Weirdly

[mmilch]

_$ echo "00" | xxd -r -p >ROP_CLEAR.bin $ stm8flash -c stlinkv2 -p stm8s105?4 -s opt -w ROPCLEAR.bin

Hi. I got ROP protected stm8s105s4 chip in e-bike controller and would like dump it's entire content (flash, eeprom and option memory). Is it 100% sure that doing above trick will result in a lost of original flash memory ?

[julianrendell]

Summary: check your grounding!

I was having similar issues, but none of the above worked.

In frustration I tried connecting the USB power and programmer in at the same time (same PC!) Things magically worked with out issues(!) I disconnected the USB power and it started failing again. It wasn't power supply; I could get it to work again by just touching the USB cable plug to the socket metal.

[hkaze]

Thanks @julianrendell , in addition to the "protected chip" issue, all my 4 samples of STM8S103F3P6 boards (bought from China) had the same GND problem.

I marked my findings with my multimeter:

• "RED X": This GND (aligned with SWIM signals) is NOT connected to anywhere. I recommend NOT to use it.
• "GREEN V": This GND is connected and it works. I recommend to use it.
• Using the "Green V GND" I could successfully flash the STM8S103F3P6 using only the STLINKV2 (also bought from China) interface, without having to power by USB:
  • 3V3
  • SWIM
  • "Green V GND"
  • NRST

I apologize because I know this hardware problem may be specific to (all) my boards, or my vendor, but I hope my findings can be useful for someone.

[prosper00]

I had the same problem. I tried to troubleshoot, but, in the end, I just ended up replacing my stlink with a different one and the problem went away. I have no idea what the problem is, but it's looking like something to do with the stlink dongle hardware. There are a bunch of variants out there, and no doubt a few 'bad' batches.

I also have the 'gnd pin not connected' issue noted above. That, at least, is an easy fix. Use the GND pin on the board as noted, or, it's fairly straightforward to scrape off a bit of mask from the fill around the ground pin, and solder in a wire to a convienent ground point elsewhere on the board: