Forum: Mikrocontroller und Digitale Elektronik STM32F103 Bluepill mit 128kb lässt sich nicht flashen


von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

die neuen BP, die ich erhalten haben weisen sich bei St-link mit 128kb 
aus. Chip sehen orgonal aus, sind sie aber sicher nicht. STM32F103C8T6

Sie lassen sich mit st-link löschen aber leider nicht mit dem Embitz 
Debugger beschreiben.

In den Link dateien habe ich die ROMSIZE auf 128kb angehoben.

Bilder habe ich angehängt. Gibt es da einen Kniff wie man das beheben 
kann?

Gruss,
Christian

von Stefan F. (Gast)


Lesenswert?

Sind wahrscheinlich Fälschungen. Seit Anfang 2020 sind alle 
BluePill-Boards mit schlecht funktionierenden Fälschungen bestückt.

Eventuell kannst du sie seriell flashen, wenn du Glück hast.

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Eventuell kannst du sie seriell flashen, wenn du Glück hast.

Ja, über die Arduino IDE lassen sie sich flashen aber ich arbeite nicht 
mit Arduino bei STM32.

Nix zu machen, auch der aktuelle st-link GDB Server will sie nicht. Da 
ich 10 Stück gekauft habe kriegt der ebay Fritze sie auch zurück. Grad 
nen Fall aufgemacht.

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Ja, über die Arduino IDE lassen sie sich flashen aber ich arbeite nicht
> mit Arduino bei STM32.

Die haben einen seriellen Bootloader, den du mit Software von ST nutzen 
kannst. Setze dazu Boot0=HIGH. Damit meine ich nicht den (zweiten) 
Arduino Bootloader im Flash.

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Die haben einen seriellen Bootloader, den du mit Software von ST nutzen
> kannst.

Und was hat das mit der SWDIO Schnittstelle zu tun? Ist alles witzlos, 
wenn nicht das JTAG Debug Interface nutzbar wird. Das mit dem Jumper 
habe ich mal für ausgesperrte Chips benutzt, damit die wieder 
beschreibar wurden. Es ist zum k*** mit diesen ganzen Fake Chips 
inzwischen!

Embitz hat einen eigenen st-link Server von 2016 eingebaut. Mit dem 
neuen ist das gar nicht zu machen, der bricht direkt ab, selbst bei den 
64k versionen. Und leider so schnell dass man nichts sieht.

Ich frickel den jetzt nochmal drauf.... 30 Minuten gebe ich mir noch das 
Teil zum sprechen zu bringen...

So, Release flashen lässt er sich aber nicht debuggen. St-Link habe ich 
ja als eigene Anwendung unter Tools installiert. Der Debug Server ist 
aber eine andere Anwendung aus dem Hause ST.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Ok, die 128kb sind jedenfalls echt, ein testfile mit 128kb lässt sich 
flaschen und verify'en. Noch schöner wenn es sich auch debuggen liesse, 
mit 128kb wären alle meine Sorgen gelöst, da ich inzwischen bei 58kb bin 
mit meiner Anwendung.

Edit: Nix zu machen auch nicht mit einem Testprojekt und einer 128kb 
Type. Dann meckert er die Core-ID an, dass die nicht stimmt.

von randomusername (Gast)


Lesenswert?

Mach einen zur BlackMagicProbe  per seriellem Flash und programmier den 
Rest damit, wär potentiell eine Möglichkeit die Dinger mit SDW-Interface 
zum Laufen zu bekommen.

von Andreas B. (bitverdreher)


Lesenswert?

Dazu hier:
Beitrag "Black Magic Probe auf ST Link v2 clone "baite""

Es handelt sich übrigen i.A. um einen CS32F103C8T6, der eine andere ID 
hat. (0x2ba01477 statt 0x3ba00477). Wenn Du diese in den Tiefen Deiner 
Embitz Konfiguration einstellen kannst, wäre dies eine Möglichkeit.
Zum Thema (u.A.):
Beitrag "STM32F103C8T6 - Fälschung von ST bestätigt"

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Und was hat das mit der SWDIO Schnittstelle zu tun?

Nichts. Wenn dir diese Schnittstelle wichtig ist, dann schreibe das 
besser bevor du mangels Infos schlechte Antworten bekommst die dich 
verärgern.

> Ist alles witzlos, wenn nicht das JTAG Debug Interface nutzbar wird.

Genau genommen kannst du mit dem SWD Interface auch kein JTAG machen, 
das ist wieder eine andere Schnittstelle, deren Pins sich nur zufällig 
mit SWD überlappen. Aber ich verstehe was du meinst: Du möchtest 
debuggen.

> Es ist zum k*** mit diesen ganzen Fake Chips inzwischen!

Allerdings. Die Händler sollten ehrlich angeben, was sie da verkaufen. 
Dann kann sich auch ggf. drauf einlassen und mit den dazu passenden 
Datenblättern arbeiten.

von Andreas B. (bitverdreher)


Lesenswert?

Stefan ⛄ F. schrieb:
> Die Händler sollten ehrlich angeben, was sie da verkaufen.
Wobei ich mal behaupte, das dies bei den Elektronikhändlern in China 
auch so ist. Dummerweise verkaufen dort halt auch Textilhändler 
Elektronikteile.

von Stefan F. (Gast)


Lesenswert?

Ich fürchte, dass die jetzt erstmal die ganzen schlechten Fälschungen so 
lange verkaufen, bis es keine mehr gibt. Erst dann wird Platz frei für 
neue Boards (eventuell mit STM32F303).

Off-Topic:
Neulich ist mir aufgefallen, dass die Chinesen gerade den Markt mit Sets 
zum Sticken überfluten. Wenn man nach "diy kit" sucht, kommt man in 
sämtlichen Shops auf Unmengen runder Ringe aus Holz mit Tüchern und 
bunten Fäden. Als gäbe es nichts anderes mehr.

von Andreas B. (bitverdreher)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich fürchte, dass die jetzt erstmal die ganzen schlechten Fälschungen so
> lange verkaufen, bis es keine mehr gibt.
Jetzt mal eine Frage: Sind das wirklich Fälschungen mit STM Logo und 
Beschriftung oder steht da CS32F103C8T6 drauf?
Bis jetzt war es bei mir nämlich immer so: Wenn STM draufsteht ist da 
auch STM drin.

von Stefan F. (Gast)


Lesenswert?

Andreas B. schrieb:
> Bis jetzt war es bei mir nämlich immer so: Wenn STM draufsteht ist da
> auch STM drin.

Dann hattest du Glück. Ich hatte auch Glück, das war aber Ende 2019. Von 
dem Vorrat zehre ich noch.

Wann hast du deine "guten" gekauft?

von Andreas B. (bitverdreher)


Lesenswert?

STM war schon länger her. Diejenigen, die CS32F103C8T6 drauf haben, sind 
auch nicht mit STM beschriftet.
Tip: Beim Blackpill sind noch die originalen STM32F411CEU6 drauf. 
(Jedenfalls war das vor 2 Monaten noch so).
Man kann hier von Täuschen sprechen, wenn die Dinger als STM verkauft 
werden. Fälschen ist was anderes.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Na, dann bin ich ja mal gespannt..... ich will ihm die 10 Pillen 
zurückschicken.

Die Chipse sind übrigens mit ST Schriftzug und ST Logo beschriftet, 
wobei das letzte auf China hindeutet.

STM32F103C8T6
GH209
CHN215

PS: Den Versuch die zahlreichen Versinen der 103er bei Embitz zu testen 
habe ich hinter mir. Die T6 benutzt mit 128kb. Tut es alles nicht. Durch 
die Abfrage der Core-Id in der st-link Software wird das alles geblockt. 
Nur bei openocd lässt die sich einstellen aber das kriege ich leider 
nicht zum Laufen weil ich nicht weiss wie.....

von Andreas B. (bitverdreher)


Lesenswert?

Christian J. schrieb:
> Nur bei openocd lässt die sich einstellen aber das kriege ich leider
> nicht zum Laufen weil ich nicht weiss wie.....
Bei Linux Mint 20 ist es:
/usr/share/openocd/scripts/target/stm32f1x kopieren nach 
cs32f103c8t6.cfg
dort nach:
set _ENDIAN little
einfügen:
set CPUTAPID 0x2ba01477

dann aufrufen mit:
-f target/cs32f103c8t6.cfg

von Christian J. (Gast)


Lesenswert?

Andreas B. schrieb:
> Bei Linux Mint 20

Leider vor 1 Jahre mangels Notwendigkeit vom Rechner geflogen. Sehr 
schade aber Linux war zu wenig in Benutzung.

von Andreas B. (bitverdreher)


Lesenswert?

Mag ja sein, aber Win wird das ja wohl ähnlich haben. Die Verzeichnisse 
sind halt nur andere.
Bei mir ist Win halt nicht notwendig. ;-)

von Christopher J. (christopher_j23)


Lesenswert?

Andreas B. schrieb:
> Es handelt sich übrigen i.A. um einen CS32F103C8T6, der eine andere ID
> hat. (0x2ba01477 statt 0x3ba00477).

Das ist so nicht ganz korrekt. Bei 0x2ba01477 handelt es sich nicht um 
die ID irgendeines speziellen Controllers (CS32F103C8T6), sondern um die 
ID des Cortex-M Kerns. Genau genommen ist es der Wert im SW-DP Register 
und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen.

Fest steht jedenfalls erstmal nur, dass es kein original STM32 ist. Ein 
CKS32 kann es meiner Meinung nach aber auch nicht sein, weil der 
tatsächlich nur 64kB Flash hat.

von Christian J. (Gast)


Lesenswert?

Weiss ein Embitz user vielleicht wie man das hier so aufsetzt für Source 
Level Debugging? Da wäre eine Anleitung für Dummies echt nett! Ist ein 
alternativer Debug Server, EBlink. Und vielleicht ist es Zeit den alten 
raus zu werfen, der ja auch von 2016 ist.

https://github.com/EmBitz/EBlink

von Pille (Gast)


Lesenswert?

Christopher J. schrieb:
> Andreas B. schrieb:
>> Es handelt sich übrigen i.A. um einen CS32F103C8T6, der eine andere ID
>> hat. (0x2ba01477 statt 0x3ba00477).
>
> Das ist so nicht ganz korrekt. Bei 0x2ba01477 handelt es sich nicht um
> die ID irgendeines speziellen Controllers (CS32F103C8T6), sondern um die
> ID des Cortex-M Kerns. Genau genommen ist es der Wert im SW-DP Register
> und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen.
>
> Fest steht jedenfalls erstmal nur, dass es kein original STM32 ist. Ein
> CKS32 kann es meiner Meinung nach aber auch nicht sein, weil der
> tatsächlich nur 64kB Flash hat.

Wahrscheinlich Apex Micro wie bei meinen...

Pille

von 900ss (900ss)


Lesenswert?

Ich habe Anfang des Jahres beim Ali original STM32 Blue Pill bekommen. 
Es war ein Händler WeAct Studio.

https://de.aliexpress.com/item/1005001474741936.html?gps-id=pcStoreJustForYou&scm=1007.23125.137358.0&scm_id=1007.23125.137358.0&scm-url=1007.23125.137358.0&pvid=2d706a46-7de6-4af3-9091-65979b64925d&spm=a2g0o.store_home.smartJustForYou_6000147819213.3

Die letzten Bewertungen zeigen auch dass Original Chips verwendet 
werden.

Es gab hier im Forum aber auch jemand, der angeblich kein Original von 
denen bekommen hat. Da waren aber noch beide Varianten im Shop 
erhältlich, also original und nicht. Das war explizit ausgewiesen. 
Vielleicht fragst du dort bei dem Shop mal und bei positiver Meldung 
bestellst du dort.

: Bearbeitet durch User
von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Dann hattest du Glück. Ich hatte auch Glück, das war aber Ende 2019. Von
> dem Vorrat zehre ich noch.

Stefan,

hast du jemals versucht EBlink Debug Server mit Embitz 1.11 zum Laufen 
zu kriegen? Ich habe da gestern alles versucht. Er meckert die 
Parameterliste an, -I und -S würden fehlen. Ich habe diese Parameter 
überall versucht einzutragen aber scheinbar wird diese Liste nicht beim 
Aufruf mitgegeben. Für sich allein lässt sich das Teil mit dem STM32 
über cmd verbinden. Alles verscuht, mi Generic Device und auch dem EB 
Plugin was man sich runterladen kann.

So wie beschrieben im Embitz Forum geht es jedenfalls nicht.

von Andreas B. (bitverdreher)


Lesenswert?

Christopher J. schrieb:
> Das ist so nicht ganz korrekt. Bei 0x2ba01477 handelt es sich nicht um
> die ID irgendeines speziellen Controllers (CS32F103C8T6), sondern um die
> ID des Cortex-M Kerns. Genau genommen ist es der Wert im SW-DP Register
> und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen.
Dann hätte der TO ja einen M4 Kern.
Da die beschriebene Vorgehensweise bei mir gut funktioniert hat, kann 
ich mir das nicht so recht vorstellen.


Christian J. schrieb:
> So wie beschrieben im Embitz Forum geht es jedenfalls nicht.
Hmm, bevor Du Dir jetzt einen Wolf suchst, würde ich es ja erst mal mit 
originalen STM versuchen. Eine Baustelle nach der anderen .....

von Christian J. (Gast)


Lesenswert?

Andreas B. schrieb:
> Hmm, bevor Du Dir jetzt einen Wolf suchst, würde ich es ja erst mal mit
> originalen STM versuchen. Eine Baustelle nach der anderen .....

Tja, die 128kb lassen sich ja flashen mit st-link. Habe ja eine dummy 
Datei eingespielt und verified. Null Fehler, die sind echt! Und die 12kb 
reizen mich eben, da ich damit alle Probs los wäre.

Und Eblink hat sicherlich nicht diese nervigen Einschränkungen. Aber da 
ich keine Ahnung habe was Embitz da für einen command string zusammenbau 
ist das nur Stochern im Nebel. st-link wird ja mitgeliefert und openocd 
aber das läuft auch nicht. Blinkt nur kurz was auf und dann ist das 
Fenster weg.

Das ST-Link läuft mit diesen China Dongeles ja auch nur so "lala" Ich 
habe etliche Abstürze, die durch ziehen und stecken des Dingles wieder 
weg sind. Nach einem Debug Lauf scheitert der Relase Lauf, da muss man 
mit st-link wider "freischalten" usw. Habe ich mich aber dran gewöhnt.

von Andreas B. (bitverdreher)


Lesenswert?

Christian J. schrieb:
> Tja, die 128kb lassen sich ja flashen mit st-link.
Ich dachte, es ginge Dir um das debuggen. So hatte ich das Anfangs 
verstanden.
Schau Dir wirklich mal Black magic probe an.

von Christian J. (Gast)


Lesenswert?

Andreas B. schrieb:
> Schau Dir wirklich mal Black magic probe an.

Teures Ding. Und was ist damit anders? st-link ist ja auch ein swdio 
debugger. Spielt es mit meinem Embitz zusammen? Denn ohne ein Interface, 
was die Kommandos der IDE umsetzt und die Rückmeldungen auswertet nützt 
das leider alles nichts. Debug Server sind komplexe Tools. Und 
Kommandozeilen-Debugging kommt im Jahre 2021 echt nicht mehr in Frage.

von Andreas B. (bitverdreher)


Lesenswert?

Christian J. schrieb:
> Teures Ding.
Öhm, ich habe das auf ein Fake STM-link aus der Bucht daraufgeflasht. 
Kosten <5€.
Du hast Dir noch nicht mal die Mühe gemacht, den o.a. Link zu lesen. Ich 
bin damit raus.

von Christian J. (Gast)


Lesenswert?

Andreas B. schrieb:
> Öhm, ich habe das auf ein Fake STM-link aus der Bucht daraufgeflasht.
> Kosten <5€.
> Du hast Dir noch nicht mal die Mühe gemacht, den o.a. Link zu lesen. Ich
> bin damit raus

Auch das sagt mir nichts, wozu das Ding gut ist und ob man es in eine 
IDE integrieren kann, die Source Level Debugging im C Code + Asn und 
Life Watches und Data Breakpoints. Ebensowenig wie die zig andere 
Artikel darüber. Nur dass manche Leute sich da irre 
Kommandozeilenschlachten abliefern a la Jahr 2000 wo das noch üblich war 
und man mich beruflich bei Renesas mit dem ARM7TDMI quälte für den die 
ersten Toolchains gebaut wurden.

Denn alleion für das st-link gbt es für den laien kaum verständliche 
Scripte in der IDE, die genau das machen: Ein Interface herstellen. Mein 
Gehämmer auf den Tasten und Mausgeklicke umwandeln in DBG Server Befehle 
und auslesen der Rückmeldungen.

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
> a la Jahr 2000 wo das noch üblich war
> und man mich beruflich bei Renesas mit dem ARM7TDMI quälte für den die
> ersten Toolchains gebaut wurden.

dann ist es um so unglaublicher was du da für einen Unfug schreibst.
EmBitz unterhält sich mit dem GDBServer, da hat man nix mit zu tun. Man 
muss dem nur beim Start mitteilen wie er sich mit dem Target verbinden 
soll. Und das wird auch EmBitz können.

von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> Und das wird auch EmBitz können.

Ja, vor 20 Jahren....  Embitz kann das! Aber dafür muss man Scripte 
schreiben .... lassen wir das, Thema ist durch. Die Klone fliegen in die 
Tonne bzw wrte ich noch auf die 42 Euro, die ich von ebay zurück will 
weil der Verkäufer sich weigert, ich kaufe mit echte 128kb Chips bei 
Mouser und löte die drauf.

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
> ich kaufe mit echte 128kb Chips bei
> Mouser und löte die drauf.

da hsst du Zeit dich zu beruhigen, die sind ausverkauft...

von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> da hsst du Zeit dich zu beruhigen, die sind ausverkauft...

Grumpf !! :-(((((

https://www.amazon.com/32-Bit-Stm32F1-Stm32F103-Lqfp100-Stm32F103Vbt6/dp/B0838WQ1BC

von W.S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Allerdings. Die Händler sollten ehrlich angeben, was sie da verkaufen.

Ach Stefan, das machen die doch. Die handeln mit allem, von Babysocken 
bis Radios oder Drehmeißeln. Da wird eben vom Großhändler eine Palette 
"BluePills" eingekauft und dann eben als "BluePill" verkauft. Ob das 
eine bestückte Leiterplatte ist oder was zum Lutschen, das weiß der 
Händler schlichtweg nicht.

Abgesehen davon ist das Herumrülpsen des TO ein bissel sinnlos. Die 
Dinger haben gewiß einen Cortex-Kern, eine STM-ähnliche Peripherie und 
sehr wahrscheinlich auch einen eingebauten Bootlader. Abgesehen davon 
sollten sie nur 64K an Flash haben, wenn sie denn kompatibel zum 
besagten STM32F103C8T6 sein wollen. Da etwa 128K zu erwarten, ist 
eigentlich ne Dreistigkeit.

Der JLink von Segger kann die STM32 auch entsperren, was wohl oft genug 
vor dem ersten Programmieren notwendig zu sein scheint. Ob das bei dem 
Geschirre von ST angesichts einer unzutreffenden ID im Chip auch geht, 
ist fraglich.

Der Bootlader kann das übrigens auch tun, allerdings habe ich bei 
einigen Typen festgestellt, daß es beim Bulk-Erase dort zu einem Latchup 
kommt. Also Spannung aus und wieder ein und der Chip ist geputzt. Mein 
kleines PC-Programm zum Benutzen des Bootladers kann ja jeder hier 
runterladen so er mag.

Abgesehen davon frag ich mich, wozu jemand ein bis zwei Dutzend solcher 
Boards braucht, wenn er gesteigerten Wert auf das Debuggen legt. Dazu 
braucht man ja schließlich nur einen einzigen µC und damit nur ein 
Board. Erst wenn alles geht braucht man dann die zwei Dutzend für die 
Bastel-Kleinserie.

W.S.

von Andreas B. (bitverdreher)


Lesenswert?

Christian J. schrieb:
> Auch das sagt mir nichts, wozu das Ding gut ist
Das findet man im 2. Eintrag einer bekannten Suchmaschine (die einem zum 
entsprechenden WIKI führt) wenn man "Black Magic Probe" als Suche 
eingibt.
Aber wer nicht will, der will nicht.

Christian J. schrieb:
> Nur dass manche Leute sich da irre
> Kommandozeilenschlachten abliefern
Bla Bla.
Noch ein Beweis von nix gelesen.

Christian J. schrieb:
> Denn alleion für das st-link gbt es für den laien
Ja, ein Wunder: Die Entwicklung mit 32 Bit Controllern ist nun mal nicht 
für den Laien gedacht. Ich sehe schon, das wird nichts.

W.S. schrieb:
> Da wird eben vom Großhändler eine Palette
> "BluePills" eingekauft und dann eben als "BluePill" verkauft. Ob das
> eine bestückte Leiterplatte ist oder was zum Lutschen, das weiß der
> Händler schlichtweg nicht.
Krass formuliert, aber wo Du Recht hast, hast Du Recht. ;-)

W.S. schrieb:
> Da etwa 128K zu erwarten, ist
> eigentlich ne Dreistigkeit.
Haben die Clones fast immer. Kann man also erwarten.

: Bearbeitet durch User
von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> da hsst du Zeit dich zu beruhigen, die sind ausverkauft...

Hier ist die Lösung, man muss st-link neu kompileren mit einer anderen 
core-id in stm32.h. Habe nur leider keine Umgebung sowas zu machen. Nur 
Windows 7 ohne alles.

https://github.com/stlink-org/stlink

von Philipp B. (nowayback)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich fürchte, dass die jetzt erstmal die ganzen schlechten Fälschungen so
> lange verkaufen, bis es keine mehr gibt. Erst dann wird Platz frei für
> neue Boards (eventuell mit STM32F303).

Unter ebay häufen sich dafür zunehmend "black pills" mit STM32F401 und 
STM32F411:
https://www.ebay.de/sch/i.html?_nkw=STM32F401

Leider ohne CAN.

von Stefan F. (Gast)


Lesenswert?

900ss D. schrieb:
> Ich habe Anfang des Jahres beim Ali original STM32 Blue Pill bekommen.
> Es war ein Händler WeAct Studio.

Herzlichen Glückwunsch! Du bist der erste - kein Scherz.

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Stefan,
> hast du jemals versucht EBlink Debug Server mit Embitz 1.11 zum Laufen
> zu kriegen?

Nein

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Philipp B. schrieb:
> Unter ebay häufen sich dafür zunehmend "black pills" mit STM32F401 und
> STM32F411:
> https://www.ebay.de/sch/i.html?_nkw=STM32F401

Wie geil ist das denn? GEIL-O-MAT! Erst mal 2 Bestellt, 256kb Flash sind 
ja ne andere hausnummer als diese popeligen 64kb mit 20kb RAM. Gucken ob 
da noch irgendwelche StdPeriph Libs passen und eine CMSIS dazu. Nur sind 
die 4er, wie vom 429 bekannt auch ne Nummer komplexer, schon was das RAM 
angeht.

von Johannes S. (Gast)


Lesenswert?

Hallelujah! Aber in einem Jahr...
Wenn der Logger die Tracks noch in Google Earth in HD anzeigen soll...
Da gibts zum Glück immer noch fettere Controller :)
Wenn du jetzt noch ein gutes OS dafür verwenden würdest. Aber nein, 
nicht schon wieder :))

von Christopher J. (christopher_j23)


Lesenswert?

Pille schrieb:
> Wahrscheinlich Apex Micro wie bei meinen...
Ja, vermutlich...

Andreas B. schrieb:
> Christopher J. schrieb:
>
>> Genau genommen ist es der Wert im SW-DP Register
>> und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen.
>
> Dann hätte der TO ja einen M4 Kern.
> Da die beschriebene Vorgehensweise bei mir gut funktioniert hat, kann
> ich mir das nicht so recht vorstellen.

Auch das ist gut möglich. Der M4-Kern beschwert sich ja nicht über 
M3-Instruktionen, nur andersherum. Müsste halt mal einer testen ob der 
bei M4-Opcodes im Fault-Handler landet.

Christian J. schrieb:
> Wie geil ist das denn? GEIL-O-MAT! Erst mal 2 Bestellt, 256kb Flash sind
> ja ne andere hausnummer als diese popeligen 64kb mit 20kb RAM.

Joa, wenn man auf den CAN verzichten kann (was wohl die meisten können), 
dann sind die F401/F411-Boards definitiv in allen belangen besser und 
nur unwesentlich teurer als ein F103C8.

> Nur sind die 4er, wie vom 429 bekannt auch ne Nummer komplexer, schon
> was das RAM angeht.

Von einem F429 sind die F411 und F401 (was die "Ausstattung" angeht) 
meilenweit entfernt, dafür aber eben auch deutlich günstiger.

Eine Sache wollte ich aber noch loswerden:
Du erwartest, dass dein Setup, bestehend aus "Billigboard" und 
"Debuggerclone" für jeweils "einsfuffzich" mit deiner 
(closed-source-one-man-show-)Lieblings-IDE zusammenwerkelt, mit einer 
Herstellerlibrary die (wie auch die IDE) seit mehreren Jahren nicht mehr 
gepflegt wird, bist dir aber "zu fein" die Zeit zu investieren um die 
zugrundeliegenden Zusammenhänge zu erarbeiten um ggf. irgendwo ein 
Skript anzupassen?
Sorry aber das passt für mich irgendwie nicht zusammen.

Ich hab ja gar nichts gegen die ganzen Chinaboards, ganz im Gegenteil, 
ich habe mich als Student riesig daran erfreut, was man für so kleines 
Geld bekommt. Wenn du aber schreibst, dass du vor 20 Jahren schon für 
Renesas gearbeitet hast, dann kann ich mir einfach beim besten Willen 
nicht vorstellen, wie dich ein Nucleo-Board vom Reichelt (etwa L432KC) 
in den finanziellen Ruin treiben sollte. Das bedeutet für dich doch 
nicht - im Gegensatz zum Studenten - das du die kommenden fünf Tage 
"Nudeln mit Tomatensauce" essen musst um das Geld wieder 
"hereinzusparen".

Sorry, wenn es vielleicht etwas persönlich wurde aber hier mein völlig 
ernst gemeinter Rat:
Kauf dir ein Nucleo-Board deiner Wahl, nimm die Hersteller-IDE dazu und 
werde glücklich damit. Du hast ein garantiert funktionierendes Board, 
mit einem garantiert funktionierenden Debugger und einer garantiert 
funktionierenden IDE und das ganze kostet dich vielleicht 15-20€. Und 
bitte sag jetzt nicht, dass du mit einer Eclipse-IDE überhaupt nicht 
klarkommst, weil die ja so langsam ist, wenn du auf der anderen Seite 
super damit klarkommst den Debugger ab- und wieder anzustecken, weil der 
sich zwischenzeitlich aufhängt.

von Christian J. (Gast)



Lesenswert?

Christopher J. schrieb:
> Sorry, wenn es vielleicht etwas persönlich wurde aber hier mein völlig
> ernst gemeinter Rat:
> Kauf dir ein Nucleo-Board deiner Wahl, nimm die Hersteller-IDE dazu und
> werde glücklich damit. Du hast ein garantiert funktionierendes Board,
> mit einem garantiert funktionierenden Debugger und einer garantiert
> funktionierenden IDE und das ganze kostet dich vielleicht 15-20€

Das weiss ich aber da ist die Sache mit dem Stromverbrauch und der Größe 
halt.... naja, man versucht hat das Maximale aus allem heraus zu 
quetschen. Habe ja noch reichlich Disco's, die steckt man auch einfach 
ein und fertig. Ging vor 5 Jahren ja auch, wie man sieht. Bei bedarf an 
407ern, ich habe noch 2 übrig.

Aber hey, ich hab da noch was.... Z80! Klappt bestimmt auch damit, eine 
UART, sorry SIO hat er zumindest :-) Und 1.5A kriegen wir auch noch 
irgendwoher...

Klar kenne ich Eclipse... es ist schweinelangsam, Java eben.

Und mal "eben" ein Debugger Skript anpassen kann auch nur der, der sich 
da sehr tief einarbeitet. Habe mir das mal angeschaut, trivial ist das 
nicht.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Andreas B. schrieb:

> W.S. schrieb:
>> Da etwa 128K zu erwarten, ist
>> eigentlich ne Dreistigkeit.
> Haben die Clones fast immer. Kann man also erwarten.
Nein, haben die Clone fast nie! Die Clones habe meist ein externes SPI 
Flash, genau in der Groesse wie angegeben. Bei STM32F103x8 ist es 
anders. Das ist der gleiche Chip wie STM32F103xB.

von Christopher J. (christopher_j23)


Lesenswert?

Christian J. schrieb:
> Das weiss ich aber da ist die Sache mit dem Stromverbrauch und der Größe
> halt....

Naja, ein Nucleo-L432KC ist definitv nicht größer als ein Bluepill-Board 
aber - richtig konfiguriert (Debugger abklemmen, mittels Lötbrücken, 
etc.) - definitiv deutlich sparsamer.

> Klar kenne ich Eclipse... es ist schweinelangsam, Java eben.

Ist nicht rasend schnell aber sicher besser als Debugger ab- und wieder 
anzustöpseln. Performantere IDEs (die ich kenne, z.B. QtCreator) 
brauchen mehr "Eigeninitiative" 
(https://doc.qt.io/qtcreator/creator-developing-baremetal.html).

Uwe B. schrieb:
> Andreas B. schrieb:
>
>> W.S. schrieb:
>>> Da etwa 128K zu erwarten, ist
>>> eigentlich ne Dreistigkeit.
>> Haben die Clones fast immer. Kann man also erwarten.
> Nein, haben die Clone fast nie! Die Clones habe meist ein externes SPI
> Flash, genau in der Groesse wie angegeben. Bei STM32F103x8 ist es
> anders. Das ist der gleiche Chip wie STM32F103xB.

Ich dachte lediglich Gigadevices hätte das mit dem externen SPI-Flash 
(im Package).

von Thomas W. (Gast)


Lesenswert?

Moin, -

Christopher J. schrieb:

> Eine Sache wollte ich aber noch loswerden:
> Du erwartest, dass dein Setup, bestehend aus "Billigboard" und
> "Debuggerclone" für jeweils "einsfuffzich" mit deiner
> (closed-source-one-man-show-)Lieblings-IDE zusammenwerkelt, mit einer
> Herstellerlibrary die (wie auch die IDE) seit mehreren Jahren nicht mehr
> gepflegt wird, bist dir aber "zu fein" die Zeit zu investieren um die
> zugrundeliegenden Zusammenhänge zu erarbeiten um ggf. irgendwo ein
> Skript anzupassen?
> Sorry aber das passt für mich irgendwie nicht zusammen.

Und vor allen Dingen, dass man heute einen Orginal-Debugger fuer 
50,00EUR kaufen kann, eine vom Hersteller unterstuetzte 
Entwicklungsumgebung ohne vierstelligen Obolus, ein Orginal-Board fuer 
20 - 50EUR. Das ist alles kein Geld. Auch im Hobby nicht. Einige meckern 
schon auf einem sehr hohen Niveau.

Auch die Webinars von ST (fuer Umme) haette ich gerne gehabt, vor 20 
Jahren.

Gruesse

Th.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Thomas W. schrieb:
> Das ist alles kein Geld. Auch im Hobby nicht. Einige meckern
> schon auf einem sehr hohen Niveau.

Also ich weiss nicht ob das kein Geld ist? Ich würde ja gerne die emIDE 
verwenden, weil die gepflegt wird aber da kann man eben nur einen J-Link 
Debugger eintragen und das ist der von Segger.

Und bei dem Preis ... für Hobby?

Ok, grad gesehen, den J-Link Edu Basic, 58 Euro.... mal angefragt ob der 
kompatibel ist zu emIDE.... und wenn dann geschieht der Umstieg noch 
diese Woche.

von 900ss (900ss)


Lesenswert?

Christian J. schrieb:
> Und bei dem Preis

Es gibt doch den J-Link EDU. Der kostet ca. 50€. Ist dann nur für none 
commercial. Der sollte doch auch mit der IDE laufen.

von Christopher J. (christopher_j23)


Lesenswert?

900ss D. schrieb:
> Christian J. schrieb:
>
>> Und bei dem Preis
>
> Es gibt doch den J-Link EDU. Der kostet ca. 50€. Ist dann nur für none
> commercial. Der sollte doch auch mit der IDE laufen.

und nicht zu vergessen den Edu-Mini für die Hälfte oder den J-Link Lite 
auf einem Nucleo-Board für "umme".

von Christian J. (Gast)


Lesenswert?


von Johannes S. (Gast)


Lesenswert?

Nein, passt nicht. Diese lite Version ist nur für die F103RB auf den ST 
Boards und will vermutlich auch den ST Bootloader sehen. Lizenztechnisch 
ist diese  Version auch nur für das ST Board und nicht für externe.

von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> Nein, passt nicht. Diese lite Version ist nur für die F103RB auf den ST
> Boards und will vermutlich auch den ST Bootloader sehen.

Wieso Bootloader? Die kommunizieren doch über die genormte JTAG oder SWD 
Schnittstelle? Oder sehe ich da was falsch? Bootloader brauchste doch 
nur für den ganzen Arduino Kram, der über RS232 eingespielt wird. Intel 
Hex Files, die in-the-field eingespielt werden. Früher hatten wir den 
Wiggler, heute gibt es diese USB To JTAG Dinger ja überall auf Basis 
eines ftdi Chips oder uC der USB anbindet.

Dann kaufe ich mir das Ding von Segger und gut is.

von Andreas B. (bitverdreher)


Lesenswert?

Christian J. schrieb:
> Dann kaufe ich mir das Ding von Segger und gut is.
??
Christian J. schrieb:
> Andreas B. schrieb:
>> Schau Dir wirklich mal Black magic probe an.
>
> Teures Ding.
<5€

von 900ss (900ss)


Lesenswert?

Christian J. schrieb:
> Also meinst du das tut es auch?
Also der ist nicht von Segger, den meine ich nicht. Ich hatte die 
Produkte genannt von Segger(!) die ich meinte.

Vielleicht fragst du einfach bei Segger nach? Aber ich würde davon 
ausgehen, dass deren Produkte zu IDE kompatibel sind. Wird vermutlich 
auch auf deren Homepage stehen. Aber selber nachschauen ist ja nicht 
modern ;)

: Bearbeitet durch User
von Andreas B. (bitverdreher)


Lesenswert?

Uwe B. schrieb:
> Nein, haben die Clone fast nie!
Meine hatten bis jetzt immer 128kB. (Bei knapp 10 Stck aus verschiedenen 
Quellen). Allerdings hatten meine originalen STM32F103C8T6 ebenfalls 
alle 128kB.
Vielleicht bin ich aber auch nur ein Glückspilz.

von Til S. (Firma: SEGGER) (til_s)


Lesenswert?

Christian J. schrieb:
> Ich würde ja gerne die emIDE verwenden, weil die gepflegt wird...

Sicher das du emIDE meinst?
http://emide.org/changelog.php

Nimm doch einfach Embedded Studio:
https://www.segger.com/products/development-tools/embedded-studio/

Welche IDEs den J-Link unterstützen findest du hier:
https://www.segger.com/products/debug-probes/j-link/technology/ides/overview-of-supported-ides/

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
>> Nein, passt nicht. Diese lite Version ist nur für die F103RB auf den ST
>> Boards und will vermutlich auch den ST Bootloader sehen.
>
> Wieso Bootloader? Die kommunizieren doch über die genormte JTAG oder SWD
> Schnittstelle? Oder sehe ich da was falsch? Bootloader brauchste doch
> nur für den ganzen Arduino Kram,

sehr wirre Gedanken, dabei ist es doch so einfach: jeder STLink hat 
einen USB Bootloader für Firmwareupdates (die auch wirklich häufig 
gebraucht werden damit er mit den aktuellen STM Werkzeugen 
funktioniert).
Und das JLink Tool nutzt den Bootloader eben um die alternative Firmware 
zu flashen oder um das wieder auf original zurückzustellen.
Aber halt nur für STM Boards und zur Verwendung mit diesen gedacht. Für 
die Basteleien mit den China Boards fängt es wie geschrieben wurde mit 
dem EDU oder mini an.

von Pille (Gast)


Lesenswert?

Uwe B. schrieb:
> Andreas B. schrieb:
>
>> W.S. schrieb:
>>> Da etwa 128K zu erwarten, ist
>>> eigentlich ne Dreistigkeit.
>> Haben die Clones fast immer. Kann man also erwarten.
> Nein, haben die Clone fast nie! Die Clones habe meist ein externes SPI
> Flash, genau in der Groesse wie angegeben.

Falsch! Genau Einer der in Frage kommenden "Clone" (sind ja Keine) hat 
das was Du beshreibst, das ist der Gigadevice GD32F103C8T6. Alle Anderen 
haben den Falsch auf den Prozessorchip.

Pille

von W.S. (Gast)


Lesenswert?

Pille schrieb:
> Falsch!

Kannst du lesen? Wenn ja, dann schau mal in das DB oder RM des 
STM32F103C8T6 und du wirst dort lesen können, daß dieser eben 64K an 
Flash hat. Punkt. Und wenn durch einen euch gnädigen Zufall da noch mehr 
an Flash sein sollte, der sogar benutzbar ist und nicht vom Hersteller 
abgeschaltet, dann darf man das eben NICHT erwarten bei einem Board, 
was angeblich einen STM32F103C8T6 oder einen dazu kompatiblen Chip 
enthält.

Irgendwie ist ohnehin dieser ganze Thread irrsinnig. Da wird gierig auf 
Chips mit nem halben MB an Flash geschaut, immer "höher, schneller, 
weiter und mehr Bässe" - und dann wird so ein Zeugs auf ein Steckbrett 
gestopft und das ist dann das Ende der Fahnenstange. Unsereiner würde 
stattdessen eine Projektentwicklung erwarten, wo am Ende ein Gerät 
steht. Also etwas anderes als ein Drahthaufen auf'm Steckbrett.

W.S.

von Andreas B. (bitverdreher)


Lesenswert?

W.S. schrieb:
> Kannst du lesen?
Wenn ja, dann siehst Du, daß Pille Dir in dem Punkt widersprochen hat, 
daß das Flash sich bei den Clones auf einem externen Flash befindet.
Und auch wenn es im DB steht, wirst Du kaum Chips finden die nur 64MB 
haben. Das man dies bei einer professionellen Entwicklung nicht 
ausnützen sollte: geschenkt.

von Johannes S. (Gast)


Lesenswert?

W.S. schrieb:
> Also etwas anderes als ein Drahthaufen auf'm Steckbrett.

und die Augen machen scheinbar auch nicht mehr mit. Der TO baut seine 
Schaltungen auf weiß gestrichenen Lochrasterplatinen auf. Künstlerische 
Freiheit würde ich das nennen wenn man sich das so an die Wand hängen 
möchte.

Zu den Clones wurde auch schon genug geschrieben, der F103C8 hat einen 
Die mit 128 kB. Zu den Alternativen gibt es Datenblätter und es sind 
Unterschiede bekannt, CKS hat nur 64 kB und GD wirbt mit mehr Speicher 
und Speed weil 128 kB im RAM gepuffert werden und dann mit 108 MHz ohne 
Waitstates laufen. Und wenn die Chips korrekt beschriftet sind kann man 
das auch Nutzen.
Für die 128 kB der STM32F103C8 muss man nur Tools haben die die 
eingebrannte Romsize ignorieren, um nix anderes ging es hier.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

>>Der TO baut seine Schaltungen auf weiß gestrichenen Lochrasterplatinen >>auf. 
Künstlerische Freiheit würde ich das nennen wenn man sich das so an >> die Wand 
hängen möchte.

Gedankenübertragung: Das war wirklich der Grund, das Brett hing 3 Jahre 
an der weissen Wand. Heizkörper Lack.

Mal ne offtopic Frage:

Habe jetzt 5 Stunden die ChatFat zum Laufen gekriegt und dabei wohl alle 
Fehler gemacht, die man machen kann. z.b. dass die SPI1 auf dem remap 
Pins mit I2C1 kollidiert, auch wenn diese SMAI Pin nicht benutzt wird. 
Und dass die SPI Pins nur teilweise mit AF angebunden werden, MISO aber 
als Input. Und noch so etliches mehr, weil ich alte Versionen von Datein 
mit neuen gemixt hatte.

Ok... der Jubelschrei war bis zur Straße zu hören als mit einer neuen 
Karte das zu sehen war. Sogar mit dem richtigen Zeitstempel der aus dem 
GPS Modul gezogen wird und in die RTC wandert.

Naja.... der Jubel hielt sich dann aber in Grenzen als ich die Stecker 
der Logic Probe endlich abzog vom SD Kartenhalter. Da kam dann wieder 
NO_FILESYSTEM als Fehler einer fopen Anweisung. Nach und nach den bösen 
Pin identifiziert, es ist der Clock. Steckt man den Stecker auf SCLK 
wieder an (auch ohne GND an der Probe) geht es wieder, zieht man ihn ab 
ist der Fehler wieder da. Lötungen auf dem Raster Board sind alle ok. 
SPI läuft mit 1Mhz und 4Mhz testweise. Leitung ca 4cm lang. Pins sind 
mit _50Mhz Flankensteilheit eingestellt.

Ohne Oszi erstmal Dunkelheit, das liegt noch im Laden bzw bei Amazon. 
Mit der Probe sieht man ja nur ideales Rechteck. Sind diese 3.3V SD 
Kartenhalter vielleicht nicht so ganz ok?

Gelobe Besserung... so schlecht sollen die ja nicht sein:
https://www.ebay.de/itm/Owon-SDS1102-Oszilloskop-Oszillometer-Speicheroszilloskop-2CH-100MHz-1GS-s-J8G8/233954818555?hash=item3678cb39fb:g:6tgAAOSw-L9garu6

von Christian J. (Gast)


Lesenswert?

Til S. schrieb:

> Sicher das du emIDE meinst?
> http://emide.org/changelog.php

Ist total veraltet wie ich dann auch gesehen habe.

> Nimm doch einfach Embedded Studio:
> https://www.segger.com/products/development-tools/embedded-studio/
>
> Welche IDEs den J-Link unterstützen findest du hier:
> 
https://www.segger.com/products/debug-probes/j-link/technology/ides/overview-of-supported-ides/

Ich habe heute bei euch den EDU bestellt und mir die Studio Version 
herunter geladen. Dann wird alles gut :-)

Beitrag #6649595 wurde von einem Moderator gelöscht.
von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Steckt man den Stecker auf SCLK wieder an
> (auch ohne GND an der Probe) geht es wieder,
> zieht man ihn ab ist der Fehler wieder da.

Was könnte die Probe beeinflussen?

GND hast du ausgeschlossen.

Kapazitive Last macht die Flanken der Signale flacher, reduziert 
Reflexionen und kurze Störspitzen.

Ohmsche Last zieht die Spannung herunter, wenn der Pin floatet (nicht 
aktiv angetrieben wird).

Diese beiden Punkte würde ich mal antesten, also mit einem Widerstand 
und einem 220pF Kondensator (nacheinander, nicht gleichzeitig). Dann 
schauen wir weiter.

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Was könnte die Probe beeinflussen?
>
> GND hast du ausgeschlossen.
>
> Kapazitive Last macht die Flanken der Signale flacher, reduziert
> Reflexionen und kurze Störspitzen.

Der Oszi ist auf dem Weg....

Maßnahmen:
RTC Pins des PortC sind gekappt, d.h. nicht eingelötet (fiese 
Störquelle)
Alle Pins beim Setup auf AIN gesetzt, dann die gebrauchten 
initialisiert.
GND kontrolliert
Elko + 100nf hinter den 3.3V DC/DC Wandler
Alle Pins nachgelötet, CuL Draht auf Minimum gekürzt (3-4cm)
Bluepill getauscht
SD Card getauscht
Spannung kontrolliert am 3.3V SD Steckplatz (kein 5V Adapter)
SPI Frequenzen bis 1 Mhz runter

Finger auf Clock oder Probekabel beheben das Problem "intermettierend", 
d.h. wohl nicht ganz.

In älteren Breadboards waren 12Mhz die Schmerzgrenze für 
"Freiluftaufbau" bei der SPI.

Der SD Sockel hat Serien 100 Ohm Widerstände zur Karte drin (102 
Aufdruck= und 2 C's drauf.

Ich tausche den Sockel dann mal, denn auch wenn ich mit dem Oszi die 
Flanken sehe nützt mir das nicht viel, da ich die Ursache nicht kenne. 
Die Datenmenge bei einem flopen mit fwrite und fclose ist leider so 
hoch, dass die Probe an die Grenzen kommt, das sind tausende Bytes, da 
sucht man sich tot.

Nervig ist leider dass die FAT erst nach fclose angepasst wird, d.h. ich 
muss extra noch einen Power Down Mechanismus einbauen, sonst gibt es 
Datenmüll. Schalter an/aus wäre netter.

Meine Güte, das hat schonmal funktioniert. Bei den openlog Dingern 
klappt es ja auch wunderbar. Wieso ausgerechnet jetzt nicht 
mehr?`Boaaahhhhh....

von W.S. (Gast)


Lesenswert?

Andreas B. schrieb:
> Und auch wenn es im DB steht, wirst Du kaum Chips finden die nur 64MB
> haben.

Erstens steht das nicht im DB des STM32F103C8T6 - und zweitens findet 
man eher ganz wenig bis gar keine Controller, die satte 64 Megabyte an 
Flash auf dem Chip haben.

Warum schreibst du sowas? Bloß um auch was dazu zu schreiben? Dieser 
Thread und auch andere Threads sind voll von Gejammer über angebliche 
Inkompatibilitäten.

Man will die ach so billigen BluePill-Boards in Massen ordern, die weit 
jenseits des normalen Bastlerbedarfes sind - ohne zu bedenken, daß da 
mittlerweilen aus Preisgründen eben andere Chips drauf sind, die 
durchaus ihren Dienst versehen können, wenn man sie so akzeptiert, wie 
sie eben sind. Aber nein, man will zugleich auch seine "Gewohnheiten" 
erfüllt sehen, also 128K, vollkompatibel zum STM32F103C8T6 und so 
weiter.

Ich sag's nochmal: Wenn all die Jammerer zu rechten Zeiten ihre 
Programmiergewohnheiten dahin geändert hätten, daß sie eben 
weitestgehend unabhängig sind von einem einzigen Hersteller, dann hätten 
diese Leute anstelle herumzujammern sich einfach andere Boards machen 
lassen und Chips von anderen Herstellern draufgelötet oder löten lassen.

Vielleicht hätte sich daraus dann auch eine Szene aus 
herstellerunabhängigen Treibern, Middleware usw. entwickeln können - und 
ich meine hier ausdrücklich nicht sowas wie CMSIS.

W.S.

von Andreas B. (bitverdreher)


Lesenswert?

W.S. schrieb:
> Erstens steht das nicht im DB des STM32F103C8T6
Seite 109: https://www.st.com/resource/en/datasheet/stm32f103c8.pdf

von Stefan F. (Gast)


Lesenswert?

W.S. schrieb:
> Man will die ach so billigen BluePill-Boards in Massen ordern, die weit
> jenseits des normalen Bastlerbedarfes sind - ohne zu bedenken, daß da
> mittlerweilen aus Preisgründen eben andere Chips drauf sind, die
> durchaus ihren Dienst versehen können, wenn man sie so akzeptiert, wie
> sie eben sind.

Wenn da drin ist, was drauf steht und es auch korrekt bezeichnet 
verkauft wird, kann ich mich am richtigen Datenblatt orientieren. Chips 
die fälschlicherweise als STM32F103C8T6 beschriftet oder verkauft 
werden, sind nicht akzeptabel. Das war schon immer betrug und wird es 
auch bleiben, ganz egal wie du es zu rechtfertigen versuchst.

W.S. schrieb:
> zweitens findet man eher ganz wenig bis gar keine Controller,
> die satte 64 Megabyte an Flash auf dem Chip haben.

Ich hofee du bist klüger als dieser Satz suggeriert. Es ist doch klar 
wie Kloßbrühe, dass er 64kB gemeint hat. Du wolltest das nur nicht 
erkennen, um etwas zum meckern zu haben.

von Andreas B. (bitverdreher)


Lesenswert?

Stefan ⛄ F. schrieb:
> Du wolltest das nur nicht
> erkennen, um etwas zum meckern zu haben.
Er hat mich schon wg. KICAD auf den Schirm. ;-)

von Johannes S. (Gast)


Lesenswert?

W.S. schrieb:
> Aber nein, man will zugleich auch seine "Gewohnheiten"
> erfüllt sehen, also 128K, vollkompatibel zum STM32F103C8T6 und so
> weiter.

der TO hat gezeigt das er einen 128 kB Chip hat:
Beitrag "Re: STM32F103 Bluepill mit 128kb lässt sich nicht flashen"

alles andere sind wieder die typischen W.S. Interpretrationen.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Stefan ⛄ F. schrieb:

> Ich hofee du bist klüger als dieser Satz suggeriert. Es ist doch klar
> wie Kloßbrühe, dass er 64kB gemeint hat. Du wolltest das nur nicht
> erkennen, um etwas zum meckern zu haben.

Klar..... was sonst? Meine Tochter hat mir aber ihr neues Bluepill-Board 
mitgebracht. Ich gucke mal wieviel KB das hat und wie schnell man das 
takten kann :-)

von Johannes S. (Gast)


Lesenswert?

126 kB, steht doch da :)

von Thomas Z. (usbman)


Lesenswert?

Ich habe eine kurze Übersicht über diese chin. Arm Chips gefunden. 
Leider in Chinesisch aber Google liefert eine ganz brauchbare 
Übersetzung. Da wird auch dargestellt dass die Teile nicht in allen 
Einzelheiten den STM Chips entsprechen. Am weitesten weg vom STM103 ist 
wohl der der WCH der eine zusätzliche USB Schnittstelle hat. Dieses Teil 
ist auch mit RISC Kern verfügbar.
Speziell bei WCH gibt's nur Chin. Datenblätter die haben nur den chin. 
Markt im Visier.
Der Text enthält auch etwas nationalistische Phrasen, die sind wohl 
notwendig wenn ein Blog in China uberleben soll.
Die Teile sind wohl für den Internen Markt gedacht, und würden nie dazu 
designed 100% kompatibel zu STM zu sein.

Hier der Link
https://www.cnblogs.com/phyger/p/14277317.html

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

@Stefanus:

Mein Oszi lässt weiter auf sich warten. Aber die SD Geschichte hat mir 
keine Ruhe gelassen.

Aufgabe: Verbinde 4 CuL Drähte mit einer SPI
Schwierigkeitsgrad: Anfänger

Bei openlog spielt das einwandfrei mit einem 328er AVR. Wieso nicht bei 
diesem verfluchten Pillen Board?

Ich habe diesen Murks hier eingebaut:
https://www.ebay.de/itm/MicroSD-Breakout-Board-fur-SD-TF-Karte-fur-Arduino-3-3V-6Pin/272215736621?hash=item3f6152812d:g:gmQAAOSwuoZgG3OA

Und einfach mal die 10k Widerstände gebrückt. Weil ich dachte die liegen 
in Seie er 4 Leitungen. Pustekuchen, danach hatten alle Leitungen 
Masseschluss.

Die Teile sind 10k Pulldown's! Häh wieso das? Der STM32 kann doch kaum 
was treiben, vielleicht 3ma pro Pin. Der AVR aber einiges mehr, 20mA 
schafft der. Da wird sogar SCLK noch mit einer LED belastet... sehr 
clevere Lösung, ein Transistor war wohl zu teuer.

Da werden die Signale sicher lecker ausschauen.

Hier das Vergleichsschema vonh openlog, da sind überhaupt keine 
Widerstände drin.

Ich vermute mal, dass diese SD Cardf Klo's für Arduino gemacht wurden 
und auch nur da laufen sie.

Jetzt mal versuchen die Brücken wieder zu entfernen an diesem winzigen 
Kram.... man wird eben doch älter.

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Bei openlog spielt das einwandfrei mit einem 328er AVR.
> Wieso nicht bei diesem verfluchten Pillen Board?

Ich traue mich ja kaum es zu sagen, aber: Vielleicht weil auf dem Board 
ein schlecht gefälschter STM32 sitzt.

> Der STM32 kann doch kaum was treiben, vielleicht 3ma pro Pin.

Eigentlich garantiert ST gültige Logikpegel bis 8mA und 25mA 
Belastbarkeit.

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich traue mich ja kaum es zu sagen, aber: Vielleicht weil auf dem Board
> ein schlecht gefälschter STM32 sitzt.

Nein.... die Daten sind ja da. Ich habe ja auch schon zwei Pillen 
miteinander verbunden um zu testen, wo die Grenze der Frequenz ist. Der 
eine ballert den anderen mit Dummys voll und der andere prüft die nur. 
Da war bei 12 Mhz Schicht und das kleine Transistorradio im Raum spielte 
auch nur noch Byte-Musik ab.

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Da wird sogar SCLK noch mit einer LED belastet... sehr
> clevere Lösung, ein Transistor war wohl zu teuer.

> Da werden die Signale sicher lecker ausschauen.

Das ist schon Ok, daran wird es nicht liegen.

von Christian J. (Gast)


Lesenswert?

Stefan... Du kannst nicht eine Datenleitung auf der mit über 4 Mhz 
Datenlaufen mit einer LED belasten? Es sei denn Du hast ne Pumpe an dem 
Pin, die das locker treiben kann. Und der STM32 bringt grad mal eine Low 
Power LED zum Leuchten mit 150 Ohm Widerstand.

Was kosten originooool Pillen und welcher Dealer verkauft den Stoff? 
Robotdyn hat sie ausverkauft.

So, erstmal meine Tochter jetzt dran gesetzt, die hat noch junge Augen 
und muss trotzdem die Lupe verwenden...

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Du kannst nicht eine Datenleitung auf der mit über 4 Mhz
> Datenlaufen mit einer LED belasten

Dann muss ich wohl Geister gesehen haben, und zwar ziemlich viele.

> Was kosten originooool Pillen und welcher Dealer verkauft den Stoff?
> Robotdyn hat sie ausverkauft.

Neulich berichtete hier im Forum jemand, er habe originale bekommen. 
Allerdings mit USB-C Buchse. Sie kosteten um 5 Euro. Ich glaube das war 
bei Amazon (sagt nicht viel aus, ich weiß).

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Ok, hier ist der SD Card Plan vom freundlichen Chinesen:

Was soll das mit den Pull Ups? Bei I2C ok aber wieso bei PP Ausgängen?

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?


von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Ok, hier ist der SD Card Plan vom freundlichen Chinesen

Das passt aber nicht zu der Aussage, dass es Pull-Down Widerstände 
seien.

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Das passt aber nicht zu der Aussage, dass es Pull-Down Widerstände
> seien.

Jaaaaa.... ich konnte es nicht mehr korrigieren, weil Du schneller 
warst...

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
> Was soll das mit den Pull Ups?

macht Sinn wenn der Controller im deep sleep die IO hochohmig macht.
Welche Pins werden denn für SPI benutzt? Falls PortC, waren die nicht 
etwas schlapper als die anderen? Und in der Initialisierung muss doch 
SPI auf 400 kHz reduziert werden, ist das auch drin?

von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> Falls PortC, waren die nicht
> etwas schlapper als die anderen?

Poart A, weil Portc gibt es nicht beim BP (Pins muss man ziehen, da RTC 
hochohmig) und PortB Remap den MOSI mit dem I2C teilt (SMAI).

Ansonsten überlässt man es dem Designer was dazu baut und drängt ihm 
nicht Lösungen auf, die er vielleicht gar nicht braucht oder sogar 
stören. Aber vielleicht etwas zu viel verlangt hier. I2C Module haben ja 
auch Pull Ups, verwendet man 3 Stück hat man 3x Pull Up's parallel und 
zwingt den STM in die Knie.

Erst waren es 1 Mhz, dann 500Khz nachdem ich den APB1 auf 32 Mhz gesetzt 
habe, vorher war er 64 Mhz. Es funktioniert mit beiden nicht, die 100 
khz denke ich machen den Kohl nicht fett. Die Karte initialisiert ja 
richtig bis sie auf SPI Betrieb ist, diese Routine läuft immer 
einwandfrei durch. Ansonsten auf 48Mhz SysClock und APB1 auf 24Mhz, 
dannn dürfte es passen. Aber jetzt ist das Board zerlegt.

Ich baue das Ganze jetzt neu auf, nur die Pille und ein Adapter im 
Stecksockel, damit ich es tauschen kann. Habe diverse ohne Pegelwandler 
bestellt, wo ich den AMS117 totlegen werde für 3.3V Betrieb und schaue 
mir das dann mal genau an mit Oszi.

Und wenn alles schiefgeht kommt ein openlog rein, der lässt sich ja auch 
etwas steuern, auch wenn er weniger Komfort hat.

von Christian J. (Gast)


Lesenswert?

Ok,
nachdem alle Widerstände raus sind und die Bustakt auf ca 437 khz runter 
ist (28 Mhz Bus / 64) klappt alles bestens. Die Bits und Bytes 
schnubbeln nur so auf die Karte.

Dem Ingeniör ist nichts zu schwör :-)

von Stefan F. (Gast)


Lesenswert?

Christian J. schrieb:
> Bustakt auf ca 437 khz runter

Reicht dir das?

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Reicht dir das?

Ja, mir reichen 1.5MB / 8s Schreibgeschwindigkeit...

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Reicht dir das?

375 khz jetzt bei 48Mhz Coreclock und APB1 = 24 Mhz... damit bist Du 
auch sicher zufrieden :-))

von Stefan F. (Gast)


Lesenswert?

Jetzt bin ich verwirrt, ich dachte die 437 kHz seien die SPI 
Taktfrequenz. Aber damit komme ich nicht auf 1.5MB / 8s.

von Christian J. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Acho so, ich dachte die 437 kHz seien die SPI Taktfrequenz.

Nee, die MMC Spec verlangt die 400 khz für die Init Sequenz zur 
Umschaltung in den SPI Mode, erst danach kannst du aufs Gas treten. Ich 
werde versuchen die nächsten SD Anwendungen aber mit der SDIO zu 
machen,sofern ich dafür Code finde für den 411er. Ich schreibe grad 
jetzt, wo ich tippe mal 100MB auf die Karte. Zwei Kaffee reichen wohl 
nicht, ich werde noch ein Buch lesen gehen...

von Christian J. (Gast)


Lesenswert?

Du hast ja eine Homepage, ich einen YT Kanal.... denke mal ich werde das 
alles mal in ein Video packen, damit es nicht verloren geht. Denn da 
werden alle reinstolpern, die diese Adapter verwenden. Es gibt ja nur 5V 
Teile und diese 3.3V. Und die 5V haben alle Pegelwandler drauf. Wenn 
aber in Englisch, dann geht das leider nur mit "Teleprompter" 
flüssig.... also einiges an Arbeit. "GreatScott", ein Deutscher macht 
sich die, ebenso wie Andreas Spiess aber die verdienen auch richtig Geld 
damit.

von Christian J. (Gast)


Lesenswert?

Eine Sache noch, aber wichtig:

Diese Sequenzen da unten müssen atomar sein, da sie wie ich grad merke 
zu einem Hängen führen, wenn da ein längerer Interrupt zwischen haut.

SPI_I2S_SendData(SPI1,d);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);

Warum?

Sobald das Bye im TX Register ist beginnt die Statemachine es raus zu 
schieben. Wenn alles raus ist wird das RXE Bit gesetzt. BSY braucht man 
nicht.

Schiess der INT aber genau nach dem SendData dazwischen wird die 
nachfolgende Bedingung niemals == 0. Sie steht ggf schon auf 1, weil das 
Byte raus ist und dann steht die Anwendung still. Timeout ist da eher 
ungünstig, ich schalte die Ints da einfach jetzt ab.

von Johannes S. (Gast)


Angehängte Dateien:

Lesenswert?

habe gerade auch mal eine SD card an ein Bluepill angeschlossen, mit 
Mbed kein Problem. Ich vermute ich habe den gleichen SDC Adapter, der 
funktioniert auch mit den Pullups und losen Strippen.

Das gleiche Programm läuft auf einem Blackpill mit F401 oder F411. Man 
kann auch das SDBlockDevice durch ein SPIFBlockDevice ersetzen und das 
Filesystem in ein SPI Flash legen (kann man auf die Blackpills 
auflöten).
Für das SDIO vom F4/F7 habe ich auch ein Blockdevice gebaut, eine Zeile 
ändern und es wird SDIO benutzt. Das ist praktisch für die F407 China 
Boards, da ist ein SD Halter gleich mit drauf und an die SDIO Pins 
angeschlossen.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Johannes S. schrieb:
> Ich vermute ich habe den gleichen SDC Adapter, der
> funktioniert auch mit den Pullups und losen Strippen.

Es funktioniert definitiv nicht (sicher) mit den R's. Und das ist auch 
anhand der MMC Spec eindeutig zu beweisen, die von Pull Ups von 100k 
spricht für die Leitungen, damit diese im Idle Mode nicht floaten. Und 
da sind 10k wirklich etwas sportlich. Man lese dazu mal Chan's Seite 
aufmerksam durch, denn der hat selbst jede Menge ausprobiert und seine 
Erfahrungen aufgeschrieben.

Leider explodiert mit jeder Funktion die man nutzt auch die Codesize :-(
f_sync extrem wichtig, damit man die FAT wegschreibt, alles was danach 
kommt ist bei Stromausfall zwar weg, Chan Buffert auch natürlich.

Spielt alles einwandfrei und seit diese Hürde gefallen ist habe ich auch 
die ganze Filverwaltung schnell durchprogrammiert. 2 offene Files leider 
nicht, dann explodiert die Codesize noch erheblicher, liege schon bei 
56kb bei -O3.. Debuggen kann ich aber leider nicht mehr, die Code Size 
liegt schon bei 68kb unoptimiert. Dafür halt Arduino Style, USART2 als 
Debug Interface.

von 900ss (900ss)


Lesenswert?

Christian J. schrieb:
> 56kb bei -O3..

Vielleicht ist es dir nicht bekannt, aber -Os ist die richtige 
Optimierung wenn es auf Size ankommt. -O3 eher für Speed aber da kann 
die Size dann auch schonmal wachsen.

: Bearbeitet durch User
von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

900ss D. schrieb:
> Vielleicht ist es dir nicht bekannt, aber -Os ist die richtige
> Optimierung wenn es auf Size ankommt.

Das war ein Vertipper... O2 und Os ergeben fast das Gleiche, O3 bläst es 
auf, weil die Schleife aufgelöst werden. -Og ist für Debugging, leider 
werden TestVariablen aber weg optimiert.

Sollte alles reissen wird der print_float weg optimiert... der kostet 
fast 8 kb...

Aber Postbote war grad da.... jetzt wird alles gut :-)

von Pille (Gast)


Lesenswert?

W.S. schrieb:
> Pille schrieb:
>> Falsch!
>
> Kannst du lesen? Wenn ja, dann schau mal in das DB oder RM des
> STM32F103C8T6 und du wirst dort lesen können, daß dieser eben 64K an
> Flash hat. Punkt.

Guten Morgen...
Das was Du schreibst ist Richtig, hat aber mit dem was ich anmeckerte 
Nichts zu tun. Verstehendes Lesen ist heute wohl nicht Deine Stärke.


Und wenn durch einen euch gnädigen Zufall da noch mehr
> an Flash sein sollte, der sogar benutzbar ist und nicht vom Hersteller
> abgeschaltet, dann darf man das eben NICHT erwarten bei einem Board,
> was angeblich einen STM32F103C8T6 oder einen dazu kompatiblen Chip
> enthält.

Blah..

>
> Irgendwie ist ohnehin dieser ganze Thread irrsinnig. Da wird gierig auf
> Chips mit nem halben MB an Flash geschaut, immer "höher, schneller,
> weiter und mehr Bässe" - und dann wird so ein Zeugs auf ein Steckbrett
> gestopft und das ist dann das Ende der Fahnenstange. Unsereiner würde
> stattdessen eine Projektentwicklung erwarten, wo am Ende ein Gerät
> steht. Also etwas anderes als ein Drahthaufen auf'm Steckbrett.
>
> W.S.

Irrsinnig bist wohl Du. Mein Falsch bezog sich auf die Behauptung das 
die meisten "Clones" 2 Chips enthalten würden, einen für den Prozessor, 
und einen für den Flash..und das ist falsch. Es gibt genau nur den 
GD32F103C8T6 bei dem das der Fall ist, der arbeitet den Code aus dem 
nach dem Booten im RAM ab, nachdem er aus einem seriellen Flash Chip im 
IC (!) in den RAM umgeladen wurde. Das ist nur bei einem einzigen dieser 
Clones der Fall, alle anderen haben den Flashrom auf dem Prozessor-Chip.

..und jetzt erkläre mir mal was Dein Gefasel oben mit dieser Tatsache zu 
tun hat.

Pille

von Pille (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Christian J. schrieb:
>> Du kannst nicht eine Datenleitung auf der mit über 4 Mhz
>> Datenlaufen mit einer LED belasten
>
> Dann muss ich wohl Geister gesehen haben, und zwar ziemlich viele.
>
>> Was kosten originooool Pillen und welcher Dealer verkauft den Stoff?
>> Robotdyn hat sie ausverkauft.
>
> Neulich berichtete hier im Forum jemand, er habe originale bekommen.
> Allerdings mit USB-C Buchse. Sie kosteten um 5 Euro. Ich glaube das war
> bei Amazon (sagt nicht viel aus, ich weiß).

Ich war das und es war nicht Amazon sondern Aliexpress, also einer der 
chinesischen Shops. Das war eine Plue Pill Version 2 bei der man beim 
Händler wählen konnte ob man einen CKS32 oder einen STM32 da drauf haben 
wollte. Der Händler beschrieb das er das Problem verstanden hatte..

https://de.aliexpress.com/item/4001116767437.html

..ist allerdings ausverkauft.

Der hier bietet das Selbe an:

https://de.aliexpress.com/item/32525208361.html

"Always use original ST chips"

Pille

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Stefan,

wollte keinen neuen Fred dafür aufmachen..... wieviele Backup Register 
hat die Pille und wie breit sind die? Was sind "20-Byte Data Register"? 
20 x 8Bit?

Das Handbuchn ist da etwas allgemein, weil die ja alle Typen drin 
verquickt haben.

Hab grad Ärger mit diesen Dingern.... die resetten sich aus unbekannten 
Gründen. Leider vermute ich da auch Fehler in der StdPeriph Lib. In 
meiner CMSIS habe ich auch sch einen gefunden... GetITFlag und 
GetFlagStatus vertauscht worden.

von Johannes S. (Gast)


Lesenswert?

da der x8/xB zu den medium density devices (siehe Datasheets) gehört, 
ist deine zitierte Seite doch eindeutig, 10x16 Bit.

von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> da der x8/xB zu den medium density devices (siehe Datasheets) gehört,
> ist deine zitierte Seite doch eindeutig, 10x16 Bit.

Da steht 20-Byte... also so eindeutig ist das wohl nicht.  1 Byte = 8 
Bit. Und Register sind keine Ram Zellen, die sind wohl nur als 16Bit 
ansprechbar.
Und de StdPeripLibs, die von 2015 sind werden ja per define und tausend 
ifdef else eingestellt. Und da sind 42 Register ansprechbar, die aber 
nicht alle hintereinander liegen. Die auch im Debugger erscheinen, 
dessen .svd ich aus dem Netzt geklaut habe, die aber wohl alle Typen 
erschlägt.

Ok, bleibt nur ausprobieren und debuggen....

von Christian J. (Gast)


Lesenswert?

Johannes,

weisst Du auch zufällig ob man den Port GPIOC_13, wo die LED dran hängt 
missbrauchen kann, um den TAMPER Takt der RTC auszugeben? Ich wollte die 
mal mit meinem neuen Oszi kalibrieren. Und dazu spielt man ja den Takt 
raus und dreht am Kalibrierregister.

von Johannes S. (Gast)


Lesenswert?

habe ich noch nicht gemacht, kann ich nur mit dem Finger auf Appnote 
2604 zeigen, 
https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html#documentation
ist mit 14 Seiten überschaubar. Ich bin da ja von der faulen Sorte und 
sehe erst nach ob das OS das unterstützt, scheint nicht so. Dann in HAL 
nachsehen und in stm32f1xx_hal_rtc_ex.c findet man ein paar Tamper 
Funktionen, das geht vielleicht auch mit der SPL.

von Christian J. (Gast)


Lesenswert?

Hallo,

klappt leider nicht, alles probiert. Aber was anderes: Ich habe alle 
meine BP getestet und die restlichen zusammen gelötet: Bei 4 Stück kommt 
beim Löschen: "Cannot Read. Please remove readout protection and retry."

Natürlich lässt sich die nicht zurücksetzen, womit auch. BP's wegwerfen?

von Stefan F. (Gast)


Lesenswert?

Ich glaube die "readout protection" protection kannst du mit dem ST-Link 
utility aus schalten. Ich hatte das auch einmal, ist aber lange her.

Da haben sie dir offenbar gebrauchte Chips verkauft.

von Johannes S. (Gast)


Lesenswert?

Sicher kann man die readout protection zurücksetzen, das führt nur 
logischerweise zum Löschen des gesamten Flash. Beschrieben zB hier:
https://stackoverflow.com/questions/25770483/how-to-protect-reading-flash-of-stm32f10x

Und das muss kein Bug oder gar gebrauchter Chip sein, eher ist da ein 
Arduino Bootloader drauf. Andere sehen das als Feature und bezahlen 
dafür sogar einen Aufpreis.

Beitrag #6655926 wurde von einem Moderator gelöscht.
von Christian J. (Gast)


Lesenswert?

Prima, hat geklappt. Hatte ich wohl übersehen, dass da die Option Bytes 
gesetzt werden können. War auch was drauf, die Blinky Appist wohl 
überall drauf.

Bin übrigens mit dem OPwon SDS1102 voll zufrieden! Wobei ich den 
Eindruck habe dass das für 165 Euro wohl vom Laster in China gefallen 
ist. Kam jedenfalls problemlos durch den Zoll durch und direkt an. 
Schönes Teilchen!

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Sag mal einer, wie kriegt man unter EmBitz die BlackPill 401 ans 
Debuggen?
Bisher steht da alles still, es wird nichts geflashed. Welchen 
Controller muss man denn da einstellen bei der Projekterstellung? Da 
sind ja einige 401er aber der auf dem Board ist nicht dabei. Da steht 
401CEU6 drauf.

Das Flashen des Release mit St-Link klappt aber problemlos. Nur eben 
nicht über den Debug Server.

Nur die RE Version hat die erkannten 512KB Flash.

/*---------------------------------------------------------------------- 
--------
 *      Linker script for running in internal FLASH on the STM32F401RE
 *----------------------------------------------------------------------- 
-----*/

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
SEARCH_DIR(.)

/* Memory Spaces Definitions */
MEMORY
{
    ROM  (rx) : ORIGIN = 0x08000000, LENGTH = 512K
    RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
}

von Johannes S. (Gast)


Lesenswert?

Und die Fehlermeldungen von STlinkGDB ? Also wenn der Autor schon 
schreibt ‚forget STLinkGDB‘...
 https://www.embitz.org/forum/thread-25.html

Beitrag #6666411 wurde von einem Moderator gelöscht.
von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Johannes S. schrieb:
> Und die Fehlermeldungen von STlinkGDB ? Also wenn der Autor schon
> schreibt ‚forget STLinkGDB‘...
>  https://www.embitz.org/forum/thread-25.html

Lass Dich abknutschen!

EBLInk endlich zum Laufen gebracht, weil das da alles etwas chaotisch 
beschrieben ist. Er ersetzt den ST Link und man muss keine neue Rubrik 
anlegen.

Jedenfalls wird der 401er geflascht, wenn auch falsch als 411er 
erkannt... und was noch besser ist:

Mein Bluepill Projekt hat endlich 128 kb ! Einige der Pillen haben diese 
ja, ca 2/3 bei mir und wie ich grad sehe wurden 78kb gebrannt und 
verified.

Und weiter gehts mit dem Code, da fallen mir doch glatt noch ein paa 
Features ein, die ich dringend brauche... Wozu float wenn auch für 
double Platz ist? :-)

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
> Lass Dich abknutschen!

ein einfaches Danke reicht mir :)

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Christian J. schrieb:
> Bisher steht da alles still, es wird nichts geflashed. Welchen
> Controller muss man denn da einstellen bei der Projekterstellung? Da
> sind ja einige 401er aber der auf dem Board ist nicht dabei. Da steht
> 401CEU6 drauf.

Ich habe STM32F401RE in EmBitz ausgewählt, anschließend eine Datei 
stm32f401ce_flash.ld mit den korrekten Daten für RAM und ROM erzeugt und 
damit die stm32f401re_flash.ld ersetzt - siehe Anhang.

Anschließend habe ich unter "Build Options" -> "Device" -> Linker Script 
den Eintrag von "./stm32f401re_flash.ld" nach "./stm32f401ce_flash.ld" 
geändert.

Ich habe neben den STM32F401CE auch noch die CC Ausführung, siehe 2. 
Anhang.

Zur Frage Debugging: Seitdem ich Win10 statt Win7 einsetze, klappt das 
bei mir nicht mehr. Irgendein USB-Problem. Das hatten damals auch noch 
viele andere EmBitz-User, die meldeten sich dort alle im Forum. Eine 
richtige Lösung wurde nicht gefunden. Das alte Forum ist wegen des 
damaligen Crashs von embitz.org aber schon vor einigen Monaten 
verlorengegangen.

Mittlerweile gibt es aber auf der neuen (noch sehr knapp gehaltenen) 
EmBitz-Seite EBLink zum Debuggen. Habe ich aber noch nicht ausprobiert.

P.S.

Zu den Anhängen: Keine Gewähr, ich habe damit bereits jeweils ein 
Projekt erfolgreich kompiliert, aber das Compilat noch nicht auf den 
401-Pills getestet.

: Bearbeitet durch Moderator
von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich habe STM32F401RE in EmBitz ausgewählt, anschließend eine Datei
> stm32f401ce_flash.ld mit den korrekten Daten für RAM und ROM erzeugt und
> damit die stm32f401re_flash.ld ersetzt - siehe Anhang.

Das habe ich auch schon gemacht inzwischen, danke aber trotzdem. Unter 
Win7 läuft das alles noch.

Hab nur gerade die veralteteten SPL Libs von 2011 gegen die 2013 
ausgetauscht, die 2011er hatte Bugs drin.

Aktuell weiss ich nicht wie man EBlink diese zeile mitgeben kann:

eblink.exe -I stlink -S auto -P ../scripts/ -G

trägt man die in Extra Options ein läuft es wieder nicht mehr.

Denn Debuggen klappt, das mit dem Release flashen leider nicht. Denn da 
steht immer noch der st-link und eblink blinkt nur kurz auf und ist dann 
weg weil ich seine Parameterliste noch nicht kenne.

von Christian J. (Gast)


Lesenswert?

Ok, ich habs, zumindest klappt es. Ob da noch was hin muss... naja.

Flashing Release:

-I stlink,dr,speed=1800 -F 
erase,verify,run,file="${TARGET_OUTPUT_DIR}${TARGET_OUTPUT_BASENAME}.hex 
"

Pustekuchen.... 128kb Flash.... brenne ich eine Testdatei bricht er nach 
ca 80kB ab mit einem Verify Fehler.... wäre ja auch zu schön gewesen, 
das Doppelte für den gleichen Preis zu kriegen.

edit: bei ner anderen Pille klappt es mit 128kb aber ich hoffe mal dass 
die Bits nicht nach kurzer Zeit vom Winde verweht sind...

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich habe STM32F401RE in EmBitz ausgewählt, anschließend eine Datei
> stm32f401ce_flash.ld mit den korrekten Daten für RAM und ROM erzeugt und
> damit die stm32f401re_flash.ld ersetzt - siehe Anhang.

Hast Du ndafür auch eine Lösung gefunden? Kommt nämlich bevor er nach 
ain reinläuft als Runtime Fehler. Die RAM Size ist übrigens 96KB bei der 
CE Version. Nicht 128kb

Vielelicht hast du ja mal auch deinen startup Code?

Hier hängt er sich auf:

#ifndef __NO_SYSTEM_INIT
    ldr    r0, =SystemInit
    blx    r0
#endif

Ich habe den hier, stammt wohl aus dem Attolic Studio

Da stimmt sowieso einiges nicht, SystemInit will auf 168 Mhz einstellen, 
der kann aber nur 84 MHz. usw. Den Code habe ich damals bei dem 
Discovery Board STM32F407 verwendet, der schnurrte auf 168. Die 407er 
kamen aber wohl danach auf den Markt.

/* File: startup_ARMCM4.S
 * Purpose: startup file for Cortex-M4 devices. Should use with
 *   GCC for ARM Embedded Processors
 * Version: V1.3
 * Date: 08 Feb 2012
 *
 * Copyright (c) 2012, ARM Limited
 * All rights reserved.
 *

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Christian J. schrieb:
> Vielelicht hast du ja mal auch deinen startup Code?

Ich verwende ein von mir angepasstes system_stm32f4xx.c, das auf allen 
STM32-Boards, die ich derzeit verwende, läuft, siehe Anhang. Gesteuert 
wird das durch Angabe von -DSTM32F4nn und HSE_VALUE. Wie gesagt, ist für 
die 4XX-Pills noch ungetestet, sollte aber funktionieren, da ich die 
Werte mittels STM-CubeMX ermittelt habe.

Für die 401-Pill mit 25MHz-Quarz ist in den Projekt-Optionen 
einzustellen:
1
-DSTM32F401
2
-DHSE_VALUE=25000000
Resultat: Clock 84MHz.

Für die 411-Pill mit 25MHz Quarz:
1
-DSTM32F411
2
-DHSE_VALUE=25000000
Resultat: Clock 100MHz.

Für STM32F401 Nucleo-Boards (8MHz Quarz):
1
-DSTM32F401
2
-DHSE_VALUE=8000000
Resultat: 84MHz.

Für STM32F411 Nucleo-Boards (8MHz Quarz):
1
-DSTM32F411
2
-DHSE_VALUE=8000000
Resultat: 100MHz.

Für STM32F407VE Black-Board und STM32F407VG Discovery Board (8MHz):
1
-DSTM32F407
2
-DHSE_VALUE=8000000
Resultat: 168MHz.

Die resultierenden Werte wie Clock-Div/Multiplier und auch Wait-States 
(wichtig!) werden darüber automatisch ermittelt.

Siehe auch Kommentare in system_stm32f4xx.c

: Bearbeitet durch Moderator
von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> system_stm32f4xx.c

Moment kurz... das ist aber nicht der Startup Code. Der ist eine ASM 
Sequenz.
Die Datei die du gepostet hast muss angepsst werden abe die liegt noch 
über dem CMSIS Layer. Ich meine den ganz unten. den .s ASM der vom GCC 
als Befehl Nr. 0 angefangen wird.

Ich wehre mich noch verzweifelt gegen HAL und CubeMX aber leider wird 
der Widerstand wohl zweckloser.... die SPL ist komplett veraltet :-(

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Resultierende Werte wie Clock-Div/Multiplier und auch Wait-States werden
> darüber automatisch ermittelt.

Da bin ich mir noch nicht so sicher. Bei meiner Datei der SPL sind da 
Tabellen hinterlegt für die MUL DIV Werte. Der F401 passt nicht den den 
alten M4 Sourcen, die setzen pauschal 168 Mhz für 407 und 417 an.

Der 401 und der 411 spielen die Musik aber mit 84 BPM ab.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Moment kurz... das ist aber nicht der Startup Code

Du hattest über falsche Clocks gesprochen, die stehen nicht im 
Startup-Code, sondern in der oben geposteten C-Datei.

Die ASM-Datei startup_stm32f4xx.S wird von EmBitz automatisch beim 
Anlegen des Projekts erzeugt und ist für alle STM32F4XX gleich. Die muss 
man nicht anpassen.

Zu Beginn in main () starte ich immer als erstes:
1
    SystemInit ();
2
    SystemCoreClockUpdate ();

Dann passt das.

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Christian J. schrieb:
>> Moment kurz... das ist aber nicht der Startup Code
>
> Du hattest über falsche Clocks gesprochen, die stehen nicht im
> Startup-Code, sondern in der oben geposteten C-Datei.
>
> Die ASM-Datei startup_stm32f4xx.S wird von EmBitz automatisch beim
> Anlegen des Projekts erzeugt und ist für alle STM32F4XX gleich. Die muss
> man nicht anpassen.
>
> Zu Beginn in main () starte ich immer als erstes:    SystemInit ();
>     SystemCoreClockUpdate ();
>
> Dann passt das.

Fank, Du hast meinen Post gelesen, oder? Sonst hat das jetzt echt keinen 
Zweck. Nicht böse gemeint.... aber die .s passt eben nicht. Defintiv 
nicht.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Da bin ich mir noch nicht so sicher. Bei meiner Datei der SPL sind da
> Tabellen hinterlegt für die MUL DIV Werte. Der F401 passt nicht den den
> alten M4 Sourcen, die setzen pauschal 168 Mhz für 407 und 417 an.
> Der 401 und der 411 spielen die Musik aber mit 84 BPM ab.

Das ist alles berücksichtigt, schau doch erstmal rein, bevor Du hier 
reflexartig antwortest. Die 401er werden auf 84MHz getrimmt, die 411er 
auf 100MHz, die 407er auf 168MHz.

Bitte erst lesen, dann schreiben. ;-)

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Bitte erst lesen, dann schreiben. ;-)

Das gebe ich jetzt man so zurück :-) Da sind Bilder dran.... 
dingelingeling :-) Läuft defintiv nicht, weder mit EBlink, noch mit dem 
ST-Link... der kommt nicht mal in die Nähe der Main(). Bei mir jednfalls 
nicht.

Habe dafür neuen Fred aufgemacht, da hier OT.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Fank, Du hast meinen Post gelesen, oder? Sonst hat das jetzt echt keinen
> Zweck. Nicht böse gemeint.... aber die .s passt eben nicht. Defintiv
> nicht.

Bei mir passt das, siehe Projekte STECCY, IRMP, 
WordClock mit WS2812 und MCURSES. Die arbeiten *alle 
einheitlich* mit ein- und derselben Startup-Datei und auch mit oben 
genannter C-Datei system_stm32f4xx.c. Und die funktionieren mit 
STM32F401, STM32F411 und STM32F407.

Wenn das bei Dir nicht passt, machst Du irgendetwas systematisch 
verkehrt.

: Bearbeitet durch Moderator
von Christian J. (Gast)


Lesenswert?

Kann sein... auch wenn ich jede Schraube bald kenne, man lernt nie aus.
Kannst du trotzdem mal die .s Datei hier dran pflastern? Und den RAM 
hast du auch falsch eingetragen bei der .ld Datei. Sind 96kb nicht 128 
kb bei der CE Version.

Die 401/411 lassen sich mit st-link gdb nicht bespielen. Hast Du Eblink 
oder was anderes? Welche Parameter hat der und wo hast du die 
eingetragen. Kann ja schon daran liegen. Bei mir nimmt der die gar nicht 
an und ich habe die EBlink Scripte alle mit drin, die IDE zeigt mir eine 
neue GUI an.

mach doch mal Snapschots von Debug Interface, allen Fenstern dort. Und 
die Projekt Einstellungen. Debug RAM nutze ich nicht, wäre aber auch mal 
nett zu testen.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Christian J. schrieb:
> Und den RAM hast du auch falsch eingetragen bei der .ld Datei. Sind
> 96kb nicht 128 kb bei der CE Version.

Ja, habe ich gelesen und zur Kenntnis genommen: Ich schrieb ja, dass die 
LD-Dateien speziell für 401CC und 401CE noch ungetestet sind.

Jedoch laufen die Clock-Einstellungen in system_stm32f4xx.c schon seit 
Jahren perfekt. Und da ist es egal, ob das ein 401RE oder 401CE ist.

Anbei das Standard-Startup-File aus EmBitz.

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> nbei das Standard-Startup-File aus EmBitz.

1:1 identisch. Tja, wieso es bei mir abstürzt ist dann wohl ... ich 
weiss es noch nicht. Da habe ich keine Ahnung, da mir das zu tief rein 
geht. Solange die Tooplchain nicht steht ist da alles vergeblich.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Die 401/411 lassen sich mit st-link gdb nicht bespielen. Hast Du Eblink
> oder was anderes?

Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf 
Win10 nicht mehr debuggen kann wegen eines USB-Problems. Bitte oben 
nochmal nachlesen, damit ich nicht immer alles doppelt schreiben muss.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Tja, wieso es bei mir abstürzt ist dann wohl ... ich weiss es noch
> nicht.

Vielleicht, weil Deine Clock-Settings und Wait-States nicht stimmen?

Ersetze doch einfach die Datei system_stm32f4xx.c mit meiner, füge die 
beiden Preprozessor-Konstanten STM32F01 und HSE_VALUE zu Deinen 
Projekt-Settings hinzu und probiere das aus. Das ist doch nicht so 
schwierig. Ich mache das schon seit Jahren so.

Ich teste das am Wochenende mal mit meiner 401er Pill. Ist bei Deinem 
Board ein 8MHz- oder 25MHz-Quarz? Bisher habe ich nur 25er Boards 
gesehen.

: Bearbeitet durch Moderator
von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Vielleicht, weil Deine Clock-Settings und Wait-States nicht stimmen?

Die .s wird abgearbeitet im Default Mode, d.h. 25 Mhz mit allen WS auf 
0, wie im Datenblatt beschrieben. Erst die RCC .c gibt dann Gas und 
stellt sie ein. Mein problem hat damit also nichts zu tun, der Startup 
weiss von allem noch nichts.

Es ist ein 25Mhz Quarz drauf, wie bei allen wohl. Ich arbeite das heute 
nachmittag aber mal ein und schaue was passiert. Vor allem die PreProz 
Konstanten dürften Wirkung zeigen, da sie ja schon den Code erzeugen, 
der ausgeführt wird.

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf
> Win10 nicht mehr debuggen kann wegen eines USB-Problems.

Ist nur so ein Rat: Das und auch weil ein gekauftes Videoschnittprogramm 
für 500 Euro mit Win10 nicht kompatibel ist läuft bei mir Win7 bis sie 
es per Fernsteuerung abschalten. Es gibt bis Dato kein Programm was ich 
privat brauche, was Win10 erfordert, da ich den ganzen Kachel Quatsch 
nicht mitmache.
Mein Medion Netbook (64GB Flash, 4 GB RAM, Dual Core) war mit Win10 eine 
Schnecke geworden, daher wieder Linux drauf, auch wenn ich da den 
Touchscreen verloren habe.

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
> Erst die RCC .c gibt dann Gas und
> stellt sie ein.

die stm32f4xx_rcc.c ist allgemeiner Code, die system_stm32f4xx.c enthält 
die spezifischen Einstellungen, und die von Frank sieht gut aus. Die ist 
auch von HAL/SPL unabhängig weil das noch in CMSIS definiert ist.

von Christian J. (Gast)


Lesenswert?

Johannes S. schrieb:
> die stm32f4xx_rcc.c ist allgemeiner Code, die system_stm32f4xx.c enthält
> die spezifischen Einstellungen, und die von Frank sieht gut aus. Die ist
> auch von HAL/SPL unabhängig weil das noch in CMSIS definiert ist.

Sobald ich heute abend meinen kaffee, ne neue Packung Fluppen und Ruhe 
habe setze ich mich mal dran. Eines nach dem anderen.

401RE Projekt erzeugen.
Linker File anpassen
Defines eintragen in PreProzessor
system_stm32f4xx.c einspielen

wenn es läuft die alte 2011 SPL gegen die 2013er tauschen, die leider 
Fehler erzeugt, da auch die CMSIS angepasst werden muss. Einfach drüber 
kopieren erzeugt jedenfalls so viele Fehler wie man nicht mehr zählen 
kann. Und da sind nichts rückgängig machen lässt immer schön Kopien 
sichern :-)

von Johannes S. (Gast)


Lesenswert?

Christian J. schrieb:
> Und da sind nichts rückgängig machen lässt immer schön Kopien
> sichern :-)

oh je.... 'git init', alles andere ist Chaos aus dem letzten 
Jahrhundert.
Ach ja, EmBitz... passt :)

Beitrag #6667052 wurde von einem Moderator gelöscht.
von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Tja,

da staunt der Laie und der Fachmann wundert sich!

DAS SCHEISSDING GÄÄÄÄÄÄHT! ES GÄÄÄÄHT!

Nachdem ich das eingebaut habe, dabei noch die CMSIS auf die 2015er 
Version gebracht habe und die alte 2011er SPL auf die 2015er gebracht.

Nur leider... es sind auch Funktionen erreichbar, die es defintiv nicht 
gibt. Ich habe mal Code vom 407er einkopiert, der 4KB Backup Ram hat. 
Altes Discovery Projekt mit einer Wetterstation. Läuft durch... dabei 
hat der 401er gar kein Backup Ram.

Die Defines habe ich dem GCC mitgegeben... denke mal der Linker kann 
damit wenig anfangen.

512kb Flash.... wie soll ich die bloss jemals vollkriegen? uGfX 
Grafikoberfläche vielleicht oder nen RTOS Unterbau? Da kommen ja ganz 
neu Möglichkeiten in Betracht ;-) die 4er sind einfach geile 
Maschinchen!

Aber ein F103er Projekt portieren mit 12 Modulen....nee, das tue ich mir 
nicht an, dafür sind die 4er zu unterschiedlich.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> DAS SCHEISSDING GÄÄÄÄÄÄHT! ES GÄÄÄÄHT!

Mit meiner system_stm32f4xx.c?

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Mit meiner system_stm32f4xx.c?

Tjoooo!

Aber ist das D vor den Defines echt richtig? Ich habe die immer so rein 
geschrieben.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Aber ist das D vor den Defines echt richtig?

Unter "C-Flags": Ja, das muss so sein.

Die Compiler-Option -D bedeutet: Es folgt unmittelbar ein Define.

-DXXX ist das gleiche wie im C-Quelltext:
1
#define XXX

-DXXX=nnnn ist das gleiche wie im C-Quelltext
1
#define XXX nnnn

Der Vorteil in den Build-Options ist, dass dieses define für alle 
C-Module gilt. Sonst müsste man das ja jede Datei schreiben.

P.S.

Unter dem Reiter "#defines" wäre das dann ohne -D, dann stellt die IDE 
dann selbst das "-D" voran. Du kannst also STM32F401 und HSE_VALUE auch 
unter "#defines" platzieren, dann ohne "-D" davor.

Warum hast Du da STM32F401CB und STM32F401RE definiert? Nur eines kann 
richtig sein.

: Bearbeitet durch Moderator
von Christian J. (Gast)


Lesenswert?

Ich habe es grad getestet, bei Embitz reicht es wenn man es ohne D in 
die Defines schreibt. Dann baut er es davor.

Ok, erstmal aus anderen projekten Code klauen und ein Basisgerüst bauen 
und das dann auf einem Stick sicher verwahren.

Ich danke Dir ganz herzlich erstmal!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> Ich habe es grad getestet, bei Embitz reicht es wenn man es ohne D in
> die Defines schreibt.

Jepp: Unter Options mit "-D", unter "#defines" ohne "-D".

von Christian J. (Gast)


Lesenswert?

So, Fenster zu, Sonnenschein draußen lassen, heute nacht ist eh 
Ausgangssperre... und ich schätze mal ich werde erst morgen mittag 
wieder aufstehen, weil das ne längere Nachtsitzung werden könnte :-) Die 
Faszination uC seit 1986 (8085 und Z80, 8051) lässt nie nach....

Werde da ggf vllt später mal verarbeiten:
https://www.youtube.com/watch?v=zmPWeF2OhoU

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank,

leider habe ich viel Ärger mit "Connection to target lost" und dann muss 
ich die Pills wieder mit ST-Link löschen und dabei Boot und NRST 
drücken. Da stimmt nochwas nicht..... an er Speed liegt es jedenfalls 
nicht. Sobald ich RUN tippe.

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank,

hast Du zufällig ein gültiges .svd File für den Debugger? Meines ist aus 
welchen Gründen auch immer ungültig.

von Christopher J. (christopher_j23)


Lesenswert?


von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> Jepp: Unter Options mit "-D", unter "#defines" ohne "-D".

Moin,
könnte vielleicht mal jemand bei seinen blauen Pillen den STOP Mode 
testen? Bei mir funktioniert der nicht. Das Teil schläft ein aber wacht 
nicht mehr auf, wenn der Int Pin (PA1) einen Flanken-INT auslöst. Den 
per RTC aufwachen lasen wäre nicht Sinn der Sache.

von Gerard Z. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf
> Win10 nicht mehr debuggen kann wegen eines USB-Problems. Bitte oben
> nochmal nachlesen, damit ich nicht immer alles doppelt schreiben muss.

Hi,

I was pointed by someone to this discussion and the complains that 
EBlink wouldn't run in windows 10.

We, project team of 12, are all working with EBlink in windows 10 
without any problems whatsoever. Also as remote debugger with remote 
desktop and various win10 releases. We are using currently the standard 
STmicro device driver (Grenoble) 2.1.0.0.

In the past we had a lot of problems with composite USB devices 
(ST-link/mass-storage etc) and older libUsb releases but since EBlink we 
never had such problems again.

I would like to have some feedback about the driver/win releases with 
the problems.

Thanks,
Gerard

P.s. Also the windows shell context menu application works nicely in 
both win7 (32/64) and windows 10.

von Christian J. (Gast)


Lesenswert?

Gerard Z. schrieb:
> We, project team of 12, are all working with EBlink in windows 10
> without any problems whatsoever.

Hi,

I use EBlink on my cheap W10 Netbook with Embitz 1.11 and China-StLink 
V2 and have no problems. The only problem I have is that I have to 
remove USB for a second when switching from Debug to Release. Same 
problem as with st-link GDP server but I can live with this.

Context Menu's? `I dont know what to do with them... where can I find a 
description?

And how can I tell EBlink to take over the parameter list from embitz 
Debug? e.g. speed It's ignored from the extra fields in the Debug / 
Server / Additional Setting section :-(

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Gerard Z. schrieb:
> Frank M. schrieb:
>
>> Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf
>> Win10 nicht mehr debuggen kann wegen eines USB-Problems. Bitte oben
>> nochmal nachlesen, damit ich nicht immer alles doppelt schreiben muss.
>
> Hi,
> I was pointed by someone to this discussion and the complains that
> EBlink wouldn't run in windows 10.

That is a misunderstanding. I only wrote that I can no longer debug 
since the change from Windows 7 to Windows 10. What I meant was 
debugging with ST-Link on Nucleo boards using the offical debugging 
method supported in EmBitz 1.11 - not EBlink..

> In the past we had a lot of problems with composite USB devices
> (ST-link/mass-storage etc) and older libUsb releases

Yes, that's exactly what I meant.

But I will try EBlink in the near future. Actually, I wanted to wait for 
Embitz 2.0, but I assume that this version will never be released. I 
understand the word "soon" to mean something other than several years 
;-)

Are the updates for EmBitz 1.11 from user "Mink" in the Embitz forum 
official updates?

P.S.

On embitz.org there is a link with the name "EmBitz 1.10" at the very 
bottom of the page, but it is actually version 1.11.

P.P.S.

I would appreciate it if before the release of EmBitz 2.0 a version 
EmBitz 1.12 would be released with the following points:

- EmBitz version 1.11
- Updates from the user Mink
- EBLink support as standard

If we have to wait even longer for version 2.0, you will run out of 
users.

: Bearbeitet durch Moderator
von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> If we have to wait even longer for version 2.0, you will run out of
> users.

...zudem Segger seit Langem mit dem Studio ein sorglos Paket anbietet, 
wenn man dazu noch die EDU Hardware kauft. Allerdings nur für amtliche 
Chips, die Klone und Derivate aus dem Reich mit 
Weltherrschaftsansprüchen werden damit nicht erkannt. Was eblink 
komplett ignoriert, der nimmt alles was den Steckern ist.

von Gerard Z. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> If we have to wait even longer for version 2.0, you will run out of
> users.


Well, if that would cost me revenues then that would be a bad thing but 
the opposite is true I'm afraid :)

I had already the feeling a couple of years back, that EB was losing its 
significancy because of the many free IDE's that came available in those 
days. Also the number of critics started to out number the positive 
feedbacks on the forums. But I'm still surprised every day how many 
downloads there are even on that bare minimum EmBitz web site.

The last couple of years I'm very busy, I'm working freelance, with all 
kind of projects which limited my time to work on EB. I'm still 
maintaining it because it's my daily workhorse IDE and if I find 
something strange I solve it right away and same with features. That's 
also why I started EBlink, I needed a solution to work with my projects. 
If I need to work on an Atmel, I add Atmel. If I need additional 
breakpoints, I will add flash breakpoints... and so on.

The IoT project I'm currently working on was planned for just a couple 
of months but it did grow bigger and bigger. EB 2.0 is almost finished 
to be published and also the old EmBitz web site is recovered and only 
needs a cleanup but I have to prioritize my customers projects, I have 
to keep the chimney smoking ( I think that's dutch)

@Christian J.

Eblink has also a windows installer. It will not only install (and 
configure) EBlink but it also installs an additional windows shell 
context menu handler. This menu handler will add an EBlink submenu to 
the standard windows right click menu so that you can easily flash a 
.elf, hex or srec file or e.g. start/stop GDB server. See attached 
picture.

EBlink is a 32 bits application and in the windows installer is both a 
32 and 64 bits shell context application and runs on older windows 
versions upto win10.

The installer also configures some environment variables for default 
EBlink parameters which are used if they are missing from the CLI. So if 
a command shell is opened in any directory you can just invoke EBlink as 
e.g. EBlink -g or EBlink -f dump=1024@0x08000000:myDump.hex

Download: https://www.embitz.org/

von Gerard Z. (Gast)


Lesenswert?

Christian J. schrieb:
>
> ...zudem Segger seit Langem mit dem Studio ein sorglos Paket anbietet,
> wenn man dazu noch die EDU Hardware kauft. Allerdings nur für amtliche
> Chips, die Klone und Derivate aus dem Reich mit
> Weltherrschaftsansprüchen werden damit nicht erkannt. Was eblink
> komplett ignoriert, der nimmt alles was den Steckern ist.

Perhaps I'm a competitor to them (which I also doubt)  but they are not 
for me, if you get what I mean.

von Christian J. (Gast)


Lesenswert?

Gerard Z. schrieb:
> Perhaps I'm a competitor to them (which I also doubt)  but they are not
> for me, if you get what I mean.

No, not a competitor.... we use Segger here in our Development 
Department and Production Unit because it is a certified tool with 
support and regular updates. I use Embitz for more than 5 years now 
(only hobby) and I am very happy with it. Sometimes i crashes but not 
very often. Not for Arduino and AVR but for everything with STM32 and 
NXP.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Gerard Z. schrieb:
> EB 2.0 is almost finished to be published

OK, then I'll wait with EBLink until EB 2.0 is released. ;-)

von Christian J. (Gast)


Lesenswert?

Frank M. schrieb:
> OK, then I'll wait with EBLink until EB 2.0 is released. ;-)

2021?
2022?

Bricht dann der Download Server genauso zusammen wie die Corona Hotlines 
hier bei Beginn der Impfungen ? :-))))

von Gerard Z. (Gast)


Lesenswert?

If there was a free and fast non java alternative (preferable portable) 
with at least live variables/expressions, decent SVD viewer and custom 
debugger plugins for specific OS debugging which don't lock me to 
dedicated hardware then I would probably abandon EB.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Gerard Z. schrieb:
> I would probably abandon EB

I think EB is the best IDE for STM32. It works very fast even on older 
PCs, is clearly laid out, very configurable and also allows you to 
specify several targets for one and the same project.

Abandoning EB is therefore not an option ;-)

von Christian J. (Gast)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Abandoning EB is therefore not an option ;-)

Das sieht aber leider so aus :-(
Ich würde auch was drum geben, wenn das kein Lost Place würde..... ist 
ja schon megageil, dass fast jedes BP Board jetzt 128kb hat, seit 
openocd durch EBlink ersetzt wurde (was sich auch noch prima über die 
cmd bedienen lässt). Nur ganz wenige überstanden den 128kb Test nicht.

von Gerard Z. (Gast)


Lesenswert?

Christian J. schrieb:
> Das sieht aber leider so aus :-(

That's the current 1.11 branch on the public server and is no longer 
maintained. As soon as 2.0 will become public those sources must also be 
made public.

von Christian J. (Gast)


Lesenswert?

Gerard Z. schrieb:
> That's the current 1.11 branch on the public server and is no longer
> maintained. As soon as 2.0 will become public those sources must also be
> made public.

Ok, Mr. "Embitz"... we grab the blue pill and keep on waiting with wet 
hands for the 2.0 version.... this summer in your local cinema :-)

von Guest (Gast)


Lesenswert?

Frank M. schrieb:
> I would appreciate it if before the release of EmBitz 2.0 a version
> EmBitz 1.12 would be released with the following points:
>
> - EmBitz version 1.11
> - Updates from the user Mink
> - EBLink support as standard

It is easy to do it. 
https://www.dropbox.com/s/szltjhs1vjo9n6e/EmBitz_1.12.exe
This is an unofficial release.
I hope Gerarard will not mind.

von Christian J. (Gast)


Lesenswert?

Guest schrieb:
> This is an unofficial release.

Ver. 1.12 Build Dec 2016 ???

Besides STM32 and ESP32 support for eblink i dont see any changes, 
compared with 1.11. Just replaced the GCC 5.2020. Works fine, smaller 
code, some additional warnings appeared.

von Christian J. (Gast)


Lesenswert?

Ja, so geht das wenn man mal eben was erneuern wird.... die Link Time 
Optimization bei 1.12 klappt nicht mehr, der Code ist nicht mehr 
lauffähig.
Also alles wieder downgraden. Das sind immerhin -20kb auf 80kb.

von Guest (Gast)


Lesenswert?

Christian J. schrieb:
> Ver. 1.12 Build Dec 2016 ???


Because it's 1.11, which has a modified version in the HEX editor.
It was done that was asked.


Frank M. schrieb:
> I would appreciate it if before the release of EmBitz 2.0 a version
> EmBitz 1.12 would be released with the following points:
>
> - EmBitz version 1.11
> - Updates from the user Mink
> - EBLink support as standard

----------------------

Christian J. schrieb:
> Optimization bei 1.12 klappt nicht mehr, der Code ist nicht mehr
> lauffähig.

Have you chosen a Release target?

von Christian J. (Gast)


Lesenswert?

Guest schrieb:
> Have you chosen a Release target?

Yes, Release. Debug still works.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Christian J. schrieb:
> die Link Time Optimization bei 1.12 klappt nicht mehr, der Code ist
> nicht mehr lauffähig.

LTO for STM32 is broken in newer gcc-arm-none-eabi releases.

von Guest (Gast)


Lesenswert?

Frank M. schrieb:
> LTO for STM32 is broken in newer gcc-arm-none-eabi releases.

gcc-arm-none-eabi 9 great support for LTO.
See if there is a check "Use Link Time Optimization" on the Linker tab 
for target Release.

von EmBitz (Gast)


Lesenswert?

Frank M. schrieb:
> But I will try EBlink in the near future. Actually, I wanted to wait for
> Embitz 2.0, but I assume that this version will never be released. I
> understand the word "soon" to mean something other than several years
> ;-)
>
> Are the updates for EmBitz 1.11 from user "Mink" in the Embitz forum
> official updates?
>
> P.S.
>
> On embitz.org there is a link with the name "EmBitz 1.10" at the very
> bottom of the page, but it is actually version 1.11.
>
> P.P.S.
>
> I would appreciate it if before the release of EmBitz 2.0 a version
> EmBitz 1.12 would be released with the following points:
>
> - EmBitz version 1.11
> - Updates from the user Mink
> - EBLink support as standard
>
> If we have to wait even longer for version 2.0, you will run out of
> users.

@Frank

Well, is was a tough birth but 2.0 is there.

It ticks your list:
- Mink's updates in the wizard
- EBlink is tightly integrated

The integration of EBlink went very well, if I may say so myself. It 
makes very fast debug sessions possible because unnecessary closure of 
EBlink is avoided as much as possible so we don't have to fill the flash 
cache again and again between sessions.

EBmonitor was sometimes going crazy on debugger stop in 1.11 and that is 
solved by redesigning that plugin.

Another novelty is the Hot plug (F6) menu option. This will launch your 
debugger and connect to the target without resetting or stopping. So 
your previous debug session is restored and all the live 
variable/expressions are available to inspect your target without 
intervention after e.g. a day running.

There is also a Flash menu item which can chip erase your device, flash 
a target or dump device memory to file.

Also a lot of bug fixes and the toolchain is now standard Launchpad 9.3.

The project file is not one-on-one compatible with 1.11 and you need 
some tweaking in the compiler/linker and debug settings.

I decided to release it without a 1.11 importer because 2.0 would not 
survive the labor pain :)

von EmBitz (Gast)


Lesenswert?

Sorry forgot the link
https://www.embitz.org

von Walter T. (nicolas)


Lesenswert?

Johannes S. schrieb:
> habe gerade auch mal eine SD card an ein Bluepill angeschlossen,

Was ist das schwarze zylindrische Modul? Ist das ein 
Absolutwertdrehgeber?

: Bearbeitet durch User
von Johannes S. (Gast)


Lesenswert?

Walter T. schrieb:
> Was ist das schwarze zylindrische Modul? Ist das ein
> Absolutwertdrehgeber?

Ein Inkrementalgeber, ein guter von Grayhill. Wie im iDrive von BMW, 
also drehen, drücken und Taster für oben/unten/rechts/links.

von Walter T. (nicolas)


Lesenswert?

Johannes S. schrieb:
> Walter T. schrieb:
>> Was ist das schwarze zylindrische Modul? Ist das ein
>> Absolutwertdrehgeber?
>
> Ein Inkrementalgeber, ein guter von Grayhill. Wie im iDrive von BMW,
> also drehen, drücken und Taster für oben/unten/rechts/links.

Soetwas wie die 60A-Serie? Gut zu wissen, dass es soetwas einzeln zu 
kaufen gibt, auch wenn der Preis für viele Anwendungen abschreckend ist.

Danke für die Antwort!

: Bearbeitet durch User
von Johannes S. (Gast)


Lesenswert?

ja, genau ein 60A18-4-020C. Der Preis ist wirklich happig, sollte mal 
für einen CarPC sein. Habe dann aber gleich einen fertigen CarPC mit BMW 
gekauft :)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

EmBitz schrieb:
> @Frank
> Well, is was a tough birth but 2.0 is there.

Congratulations!

> It ticks your list:
>
> - Mink's updates in the wizard
> - EBlink is tightly integrated

Thank you very much, I read it in the following thread 
Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!" a few days before.

> The integration of EBlink went very well, if I may say so myself.

I tested EBlink a few weeks ago and had to conclude:

- Debugging with China ST-Link works
- Debugging with original STM32 Nucleo board (ST-Link on board) does not 
work.

I will now install EmBitz 2.0 and also test EBlink again with the Nucleo 
board.

It is probably better to discuss EMBITZ 2.0 in the future in thread 
Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!" . Therefore I will 
cross-post my post there.

: Bearbeitet durch Moderator
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.