STM32F401/411: Black Pill Board: Wie auf alten IDE zum Laufen kriegen?

Ok, ist aber hier jetzt nicht Thema. Thema sind die alten Tool-Chains in 
die man sich eingearbeitet hat, die ne Menge Anpassung erfahren habe, wo 
die Debug Scripte und Werkzeuge drin sind, eine eigene GCC Version 
kompiliert wurde usw.
Da stecken nicht nur Stunden, da stecken Tage drin.

Andreas B. schrieb:
> Nimm gleich was aktuelles.

Ich will aber nicht. Da zb die von Segger an deren Hardware gebunden ist 
und keine Fake Chips aus China flashen kann, weil die Core-ID abgefragt 
wird. habe deren Debugger gleich wieder zurück geschickt, war 
rausgeworfenes Geld.

und in dem EB Forum gibt es keine Leidensgenossen? Es gibt ja doch noch 
EB Anhänger und das Blackpill ist ja auch kein Exot.
Der Fehler kann auch noch aus dem Linkerscript kommen, da holt sich der 
Startup Code ja die Adressen für Flash/Ram und die Init Daten her.

Johannes S. schrieb:
> Der Fehler kann auch noch aus dem Linkerscript kommen, da holt sich der
> Startup Code ja die Adressen für Flash/Ram und die Init Daten her.

Habe ich mit Frank schon abgeglichen, die einzigen fixen Adressen die da 
drin - neben tausend kyrptischen Befehlen - stehen sind ROM 0x800000, 
RAM 0x200000 und die Vector Table. Ist bei allen M4 gleich. Der Rest 
aller Segmente baut auf diesen Adresse auf und ist wie ein Sandwich 
geschichtet, also txt, bss, usw. usw.  Der Stack kommt von oben, der 
Heap liegt zuoberst.

Bei F407er habe ich damals (Discovery Board) noch eigene Segmente für 
BKRAM (4kb) und CCRAM (64kb) von insgesamt 196kb eingebaut und deren 
Regionen zugewiesen, da das RAM nicht an einem Stück liegt. Dadurch 
konnte ich jeder Var zuweisen wo sie liegt. zb
int var1 __section(CCRAM....)

Die hat der 401 aber wohl nicht wie ich gelesen habe bei der ersten 
Durchsicht der Reference.

es gilt wohl auich zu klären, ob das Problem nicht beim EBlink DGB 
Server liegt und dem St-Link V2 Klone. Dazu werde ich mal die berühmte 
rote LED einschalten und gucken ob der Code da hin kommt.

Andreas B. schrieb:
> Black magic Probe. Hatte ich aber in einem anderen Thread schon erwähnt

Ja, wenn mir jemand dafür das ganze Drumherum gibt, Scripte, Integration 
in die IDE usw. Dann, wenn ich mit allem was ich habe nicht 
weiterkommen, erst dann steige ich um, weil das ein Riesenaufwand ist 
einen Source Debugger ans Laufen zu kriegen. Auch wenn da der Server mit 
drin ist, EmBitz erwartet das aber nicht, der hat die ganze Bedienung 
eines Servers mit drin und zwar in Form von Scripten. Nachher liegt das 
teure Ding (60 Euro) auf dem Tisch und du fragst dich verzweifelt wie du 
es ans Laufen kriegen sollst.

Denn ich finde darüber nicht einen einzigen Hinweis, wie die BMP in 
bestehende IDE integriert werden soll! Alles so einfach? Und das scheint 
mir sehr komisch zu sein... vermutlich setzt es einfach kaum einer ein! 
Der Markt ist geschwemmt mit st link klonen aber nicht mit BMP's.

Der hier kriegt es auch nicht wirklich ans Laufen....

https://mcuoneclipse.com/2019/06/23/black-magic-open-source-debug-probe-for-arm-with-eclipse-and-gdb/

"Hi Nadu,
Building a hardware debug probe is very easy compared to the 
software/tools support. In my case the black magic debug probe is 
collecting dust because it does not support well the devices I’m mostly 
using, to bad. My recommendation is that you go straight using the 
J-Link, you will get much better and professional support that way.
Erich"

Christian J. schrieb:
> Die F103
> Chips werden immer teurer und sind mit über 10 Jahren Marktpräsens auch
> als "out of date" zu bezeichnen. Je mehr ein Chip verschwinden soll,
> desto teurer wird er gemacht, das war schon immer so. Inzwischen kosten
> STMF103, sofern noch verfügbar bis zu 20 Euro / Stück.

Klar werden Chips teurer aufgrund der niedrigeren benötigten 
Stückzahlen, wenn sich ihr Lebenszyklus dem Ende neigt, der 
STM32F103C8T6 aufm Blue Pill Board kostet aber bei Abnahme einer Rolle 
nicht einmal 3€ das Stück bei den Distributoren, selbst die teuerste 
STM32F103 Variante kostet als Einzelstück nicht mal annähernd 20€ bei 
DigiKey, die Aussage ist also Humbug.

Momentan nutzen es nur einige Händler, welche noch Chips vorrätig haben 
aus, das der Markt leergekauft wurde.

der Artikel ist von 2019, der U. Bonnes und andere haben inzwischen 
wieder viele viele Stunden Arbeit da reingesteckt auch neuere targets zu 
unterstützen (wobei F401/411 auch alte Kamellen sind).
Und man muss nicht gleich die 60$ HW kaufen, ein Bluepill lässt sich 
auch zur BMP flashen. Ich habe eine Handvoll 2,50 € STLink Clones (als 
es die noch so günstig gab) und die rennen alle wie die Wutz. In VSCode, 
nix ellenlange Scripts, 5 Zeilen Config und das wars und GCC Versionen 
kann ich nach belieben tauschen.
Auf dem Blackpill läuft seit Wochen eine LED Matrix mit Laufschrift 
'Schalke ist der geilste Club der Welt'. Geholfen hats auch nicht :(

die teurere org HW vom BMP hat Buffer für die SWD drauf, damit können 
auch andere Targetspannungen als 3,3 V genutzt werden. Sonst ist die SW 
gleich.

Christian J. schrieb:
> Ich will aber nicht.
Das Problem kenne ich :-)
Weil ich von Coocox noch nicht losgekommen bin, habe ich mir keine 411, 
sondern 401 Blackpills bestellt. Die werden von Coocox 1.7.8 noch 
unterstützt. Weiß nicht, ob Dir das etwas bringt.

Nachdem ich aber meine AVR-IDE umgestellt habe und trotz Fluchen und 
Schimpfen nicht daran gestorben bin, wede ich hier mitschmökern und 
irgendwann nochmal den Mut fassen, auch für den STM32 was Neues zu 
probieren.

Christian J. schrieb:
> Die F103
> Chips werden immer teurer und sind mit über 10 Jahren Marktpräsens auch
> als "out of date" zu bezeichnen. Je mehr ein Chip verschwinden soll,
> desto teurer wird er gemacht, das war schon immer so. Inzwischen kosten
> STMF103, sofern noch verfügbar bis zu 20 Euro / Stück.

Das stimmt so nicht. Die Chips werden immer noch in Massen eingesetzt 
und sind nicht als EOL oder NRND deklariert. Ganz im Gegenteil, die 
Teile sind so teuer, weil ST nicht hinterher kommt die zu bauen.

Jan schrieb:
> Ganz im Gegenteil, die
> Teile sind so teuer, weil ST nicht hinterher kommt die zu bauen.

Die absolute Mehrheit wird gar nicht mehr von ST gebaut. ARM hat 
Lizenzen in die ganze Welt geteilt, legal oder illegal wird da 
produziert. Die Lizenznehmer packen nur ihre Prime Cells dran. China ist 
Nr.1 und verknappt den Markt derzeit und China schert sich einen Dreck 
um Rechte. Kopieren, den Markt schwemmen und die eigentlichen Hersteller 
verdrängen heisst die Devise.

Übrigens haben nicht nur Bastler Probleme, auch bei den Firmen stehen 
Linien still, weil nicht geliefert werden kann. Gerade bei VW hier neben 
an fehlen Chips.

Andreas B. schrieb:
>> Teile sind so teuer, weil ST nicht hinterher kommt die zu bauen.
> Das betrifft momentan alle Halbleiterhersteller.

Eben, wer wie ich in einer Massen-Industrie arbeitet für Elektronik 
kennt die Sorgen... die Einkäufer wissen nicht mehr wo sie die Reels her 
bekommen sollen für die Picker, Placer und Chip Shooter. Lieferzeiten 
bis 2022...

Gabs 2002 auch mal, die große Kondensator Krise...

Vincent H. schrieb:
> oder alle Einstellungen sind futsch, oder oder oder.

oder es funktioniert einfach noch. Gerade bei LPC/MCUXpresso habe ich 
viele Updates mitgemacht und kann immer noch 10 Jahre alte Projekte 
öffnen und genauso kompilieren wie früher.
Das Problem ist nur, diese IDE mag nur LPC. Für ST gibts dann wieder ein 
anders konfiguriertes Eclipse, für Nordic wieder ein anderes. Oder man 
baut das selber mit Gnu MCU Eclipse, hat dann aber nicht mehr den 
Komfort der angepassten IDE. EmBitz ist da einfacher, ist aber leider 
eine One Man Show und es hängt im wesentlichen an dem Chef Entwickler.

Vincent H. schrieb:
> Nun, diese Zeiten sind glücklicherweise vorbei. Grad wenn du beruflich
> auch damit zu tun hast und nicht "nur bastelst" würde ich dir raten dir
> CMake anzueignen. Es gibt nichts angenehmeres als ein Jahre altes
> Projekt zu öffnen, 2x Zeilen in Bash einzutippen und ein fertiges Binary
> ausgespuckt zu bekommen.

Ich arbeite in einer Firma (Konzern) wo professionell Software 
entwickelt wird für diverse Controller in Steuergeräten, zb SPS. Und ich 
kann Dir sagen, dass da niemand mit Cmake etc arbeitet oder der 
Kommandozeile. Alle SW Arbeitsplätze sind mit IAR oder Keil ausgerüstet 
und arbeiten nur mit der IDE.  Auch der GCC findet keine Verwendung, aus 
gutem Grund sogar: Den lässt der TÜV nicht zu. Und mit denen liegen 
Verträge vor, dass auch in 10 Jahren Projekte noch importiert werden 
können.

Ich bastel aber inzwischen nur noch, meine berufliche Zeit mit Software 
liegt über 15 Jahre zurück. Seitdem macht es auch mehr Spass :-)

Debugger: Mit wäre schon geholfen, wenn mir jemand sagt, wie man dem 
EBlink Server Parameter mit gibt? Denn alles was in dieser Zeile steht 
führt dazu, dass der gar nichts mehr tut. Aktuell läuft der auf Default, 
da fehlt einiges. zb kriege ich die Speed nicht eingestellt. Aber das 
kann auch am unfertigen EmBitz liegen...

Der EBLink ist doch im GitHub, incl Beschreibung.

Christian J. schrieb:
> Und ich
> kann Dir sagen, dass da niemand mit Cmake etc arbeitet oder der
> Kommandozeile. Alle SW Arbeitsplätze sind mit IAR oder Keil ausgerüstet
> und arbeiten nur mit der IDE.

Hört sich aber ziemlich rückständig an, heutzutage wird doch eh alles 
was an Kunden rausgeht auf Build Servern durch direkte Ansteuerung von 
Compiler, Linker und co. mit z.B. Jenkins gebaut, weil es so auch Jahre 
später möglich ist, einen identischen Build wieder zu erzeugen.

Klassische Builds in der IDE, kenne ich nur noch während der 
Entwicklungsphase.