STM32F103 Bluepill mit 128kb lässt sich nicht flashen

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.....

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.

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

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

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.

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.

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.

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.

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.

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.

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...

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

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.

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

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.

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

Nein

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.

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 :))

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.

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.

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.

Also meinst du das tut es auch? d.h. der ist kompatibel zur Segger 
Software von deren Homepage?

https://www.reichelt.de/in-circuit-debugger-programmierer-fuer-stm32-stlink-v3mini-p274817.html?PROVID=2788&gclid=Cj0KCQjwsLWDBhCmARIsAPSL3_3SjPYiqlDz-lECsO9evCsVWEd5WcGi8e_pO1iRs2BgZat7DeSitZwaAkYMEALw_wcB

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.

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.

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.

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

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.

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.

>>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

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 :-)

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.

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....

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.

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.

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.

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 :-)

126 kB, steht doch da :)

@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.

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.

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.

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.

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...

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ß).

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?

Ok,

https://www.amazon.de/-/en/TECNOIOT-STM32F103C8T6-Minimum-Development-Arduino/dp/B07WSDYNQG/ref=sr_1_5?dchild=1&keywords=blue+pill+board&qid=1618132527&sr=8-5

hier sind die original bestätigten Boards..... aber bitte mal auf den 
Preis schauen!

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.

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...

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?

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.

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 :-)

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

Reicht dir das?

Stefan ⛄ F. schrieb:
> Reicht dir das?

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

Stefan ⛄ F. schrieb:
> Reicht dir das?

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

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

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...

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.

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.

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.

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.

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 :-)

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

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

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.

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

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....

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.

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.

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?

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.

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.

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!

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
}

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

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? :-)

Christian J. schrieb:
> Lass Dich abknutschen!

ein einfaches Danke reicht mir :)

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.

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...

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.
 *

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 :-(

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.

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.

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.

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.

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.

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.

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.

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.

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 :-)

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 :)

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.

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.

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!

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

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.

Frank,

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

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.

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.

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 :-(

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.

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/

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.

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.

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 ? :-))))

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.

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.

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.

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 :-)

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.

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.

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.

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?

Guest schrieb:
> Have you chosen a Release target?

Yes, Release. Debug still works.

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.

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 :)

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

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.

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 :)