Nun habe ich ein seltsames Problem dem bekannten STM8S103F3P6 Board.
Es arbeitet das zuletzt aufgespielte Programm noch ab (sendet/empfängt
über UART, TEST-LED blinkt) lässt jedoch keinen neuen Flashvorgang mehr
zu. stm8flash gibt "Tries exceeded", STVP die Fehlermeldung, dass
keine Verbindung möglich ist.
Der STM8 bleibt aber offenbar stehen, wenn ich versuche eine Verbindung
herzustellen.
Das Mysterium:
- Am ST-Link V2 bzw. der Software (stm8flash oder STVP) liegt es nicht,
ein anderes baugleiches Board funktioniert einwandfrei.
- An der Problematik, dass der SWIM-Pin als Ausgang geschalten ist kann
es nicht liegen, denn der STM8S103F3 hat einen eigenen NRST Pin und ich
nutze in meinem Code keine GPIOs (bis auf die TEST-LED, und dieser Code
ist seit Anfang der Entwicklung unverändert geblieben). Die Gefahr
sich auszusperren wie beim STM8S001J3 (reinster Murks, sorry ST) besteht
meines Wissens nach nicht.
- Den STM8 habe ich mit Flussmittel nachgelötet und auch mit
Durchgangstest verifiziert, dass die relevanten Pins (NRST und SWIM)
verbunden sind und keine Kurzschlüsse auftreten.
- Den Onboard-Reset-Taster habe ich entfernt, falls dieser defekt sein
sollte und auch manuell den NRST-Pin auf Masse gezogen.
- Ein Unlock-Kommando per stm8flash hat keinen Effekt:
1
$ ./stm8flash -cstlinkv2 -pstm8s103?3 -u
2
Determine OPT area
3
Unlocked device. Option bytes reset to default state.
4
Bytes written: 11
Der Programmcode bleibt unverändert, flashen lässt er sich weiterhin
nicht.
Weiss jemand weiter? Sind zwar nur 50 Cent, aber ich finde es einfach
schade, einen funktionierenden STM8 wegzuwerfen.
Also Factory Default, beschreiben lässt er sich trotzdem nicht. Die
Option Bytes lassen sich jedoch beschreiben, auch wenn ich da irgendwas
anderes reinschreibe bleibt das erhalten.
Noch ein Phänomen:
Der "defekte" STM8 lässt sich mit STVP nicht auslesen (auch nicht die
Option Bytes), jedoch lassen sich die Option Bytes mit stm8flash
auslesen.
Interessanterweise lässt sich sogar der Program-Flash des "defekten"
STM8 korrekt auslesen und hat den erwarteten Inhalt!
Das betrifft aber die STM8Flash-Software. Das mysteriöse ist ja, dass
ST's eigenes Tool STVP unter Windows sich überhaupt nicht mit dem Chip
verbinden will und
Nachdem ich ihm jetzt ins erste Byte "AA" programmiert habe, wie im Link
empfohlen bekomme ich beim zurücklesen der Option Bytes folgendes:
Der STM8 wurde gerettet!!!!!
Also... Der Trick mit Factory Defaults funktioniert NICHT.
Was geklappt hat: 0xAA auf das erste Option Byte schreiben.
Danach kommen die Option Bytes mit 71717171... zurück.
Danach die Factory Defaults schreiben und der Chip lässt
sich wieder beschreiben.
Dummerweise habe ich jetzt den "Beweis" vernichtet, denn
eventuell hätte sich auch ST für dieses Exemplar interessiert.
Meiner Meinung nach ein definitiver Silicon Bug, denn wozu
soll man die "Readout Protection" erst aktivieren müssen,
um sie dann wieder zu deaktivieren um danach den Chip
beschreiben zu können.
Interessant aus dem link finde ich noch
"So, I installed "ST Visual Develop", have rewritten data in OPTION BYTE
tab and my STM8S103F3P6 alive now."
Also STVD nicht STVP.
Der Chip macht jetzt was anderes "lustiges". Das neue Programm
arbeitet erfolgreich, aber die Option Bytes enthalten nur noch Müll.
Ich kann nun weder Option Bytes noch Flash beschreiben, den Flash
jedoch erfolgreich lesen.
Mit STVD zeigt sich das gleiche wie mit STVP: "Defekter" Chip lässt
sich nicht verbinden, intakter jedoch problemlos.
Für mich sieht das nach einem Silicon Bug aus - eventuell interessiert
sich ja ST dafür?
Der Chip ist somit kein "OTP", sondern ein "STP"-Device: Sometimes
programmable.
Ich schlage ST vor, folgendes Erratum zu veröffentlichen:
"Occasionally, the device cannot be programmed on weekends
or by hobbyists. On rare occasions, it may inhibit all
further programming attempts."
Workaround: Ensure that the device is programmed only during
work days in a certified lab environment. On rare occasions,
If programming still fails, use a male cat's claw to scratch
the top of the device. This reorders the electrons and thereby
causes the device to stop malfunctioning. The cat's claw may
then be removed for further programming."
Das Board ist elektrisch in Ordnung. Das Chip ein Clone/Fake sein
halte ich für beinahe ausgeschlossen, der Chip kostet in China ca. 0.22
EUR und bei Mouser 0.48 EUR. Der fast gleiche STM8S003F3P6 kostet
0.29 EUR bei Mouser, somit würden die theoretisch sogar Gewinn machen.
Kann auch gut sein, dass die Chips bei enormen Mengen in etwa gleich
viel kosten.
ST ist ja bekannt dafür, Chips "downzugraden" beim STM32 was man so
liest und mit dem STM8S001J3 haben sie sich auch nicht mit Ruhm
bekleckert:
https://hackaday.io/project/27250-mcu-how-tos-reviews-rants/log/66992-stm8s001j3-the-good-the-bad-and-the-ugly
Oder es ist tatsächlich Ausschussware die da verlötet wurde...
Hi,
for the benefit of other users with this problem, I read this and many
other threads seeking a solution. What solved it for me was to connect a
.1uF cap on VCAP to Vss and 10uF on Vdd to Vss. It then worked
immediately.
The caps are actually recommended but I was hoping to get away without
then, but "Nicht Mehr" !
John Jennings
Ireland
Thread beobachten
Seitenaufteilung abschalten