STM32F407-DISC1 Board defekt

Christoph K. schrieb:
> Hat jemand vielleicht noch ein paar Ideen?

Nur eine. Du steckst da Stunden, Tage, Wochen an Arbeit rein
(hab schon einiges darüber gelesen ....). Hirnrissig sich da
hineinzusteigern.
Dabei könntest du für geschätzte 20 Euro ein neues Board kaufen.

Discovery-compatible Boards (ohne den ganzen Klimbim den man
nicht braucht) bekommt man bei ebay für 15-20 Euro.

Christoph K. schrieb:
> Auch sind an dem Board schon einige Modifikationen
> gemacht, so daß ich es lieber erhalten würde.

Wie sollen wir dir denn gute Ratschläge geben, was kaputt sein könnte, 
ohne die Modifikationen zu kennen?

Christoph K. schrieb:
> eine
> UART-Ausgabe wäre das einzige Lebenszeichen gewesen, aber die kam
> nicht

Hat das Board keine LEDs sonst versuch doch darüber mal Lebenszeichen zu 
bekommen? Ich glaube auch nicht, dass es den Aufwand wert ist.

Christoph K. schrieb:
> ich programmiere den Chip mit
> der ST-LINK SWD-Sektion eines Nucleo-Boards

Warum nicht über den eigenen ST-Link?

Wenn du das Board unbedingt retten möchtest kannst du dir ja auch mal 
den Schaltplan angucken und überlegen wo die falsche Spannung schaden 
könnte. Da du ja einiges modifiziert hattest und nicht allzuviel 
Informationen genannt hast ist es aus der Ferne schwer abzuschätzen was 
es zerbraten hat ;)

Christoph K. schrieb:
> Man muß sich vorstellen, daß das Discovery so
> verändert wurde, daß alle Pins der extenen Schaltung zur Verfügung
> stehen.

Wenn das so ist, dann ist da also kein Bauteil mehr übrig, dass für die 
Funktion relevant ist. Dann hätte der Austausch des Mikrocontroller 
klappen müssen.

Irgend etwas ist anders. Ich würde dringend empfehlen, das in Form eines 
Schaltplanes zu dokumentieren.

Christoph K. schrieb:
> Hat jemand vielleicht noch ein paar Ideen? Spannungen (3V, 5V) sind
> jeweils alle da. Werde jetzt mal den STM32F103 aus der ST-LINK Sektion
> auslöten.
Wenn Du Dir damit nicht noch mehr Fehler reinholst ... der STM32F103 
hängt mit ein paar Pins am STM32F407, die man leichter auftrennen kann 
als den 103er auszulöten.
https://circuit-diagramz.com/wp-content/uploads/2016/12/schematics_SWD_only-1.jpg
SWDIO und SWDCLK sind sowieso gejumpert und müssen nicht getrennt 
werden.

Probier doch stattdessen, den STM32103 in seiner ursprünglichen Funktion 
als STLink zu enutzen, um einen anderen STM zu flashen. Wenn er das 
kann, ist er wahrscheinlich nicht kaputt.

Christoph K. schrieb:
> Wahrscheinlich muß ich dann 4 Wochen drauf warten (China).

Ja klar, immer gleich in China bestellen. Anders geht ja gar
nicht, gell? Oh Mann, was es für Ausreden gibt .....

https://www.ebay.de/itm/STM32F407VET6-STM32-Cortex-M4-Development-Board-Mainboard-Module-NEU/233535468848

https://www.ebay.de/itm/STM32F407VGT6-STM32F4-ARM-Cortex-M4-32bit-MCU-Core-Development-Board/402328288186

Lieferung Dienstag 2. März:

https://www.amazon.de/DollaTek-STM32F407VET6-Entwicklungsboard-Lernboard-Embedded-Entwicklungsboard/dp/B07PQPCV5S/ref=sr_1_25?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3QDS7W19741HZ&dchild=1&keywords=stm32f407+discovery+board&qid=1614362048&quartzVehicle=1820-1194&replacementKeywords=stm32f407+board&sprefix=stm32f407%2Caps%2C188&sr=8-25

Christoph K. schrieb:
> Und letztlich
> weiß man nicht genau, was man bekommt (gefälschter Chip mit Mängeln).

Käse.

Hab schon viele solche Boards bestellt, waren alle in Ordnung.
F407 Chips sind bisher nicht als Fakes bekannt.

mimimimimi .....

Wenn sich jemand so im Kreis dreht dann muss man sich
echd uffregge über soviel Kleinkariert.

Christoph K. schrieb:
> Ich habe immer gesagt, ich brauche
> genau dieses Board.

Brauchst du nicht, hast du indirekt auch schon zugegeben indem
du ein anderes Board in Betracht gezogen hast.

So lange wie du an der Reparatur deines Boards herumgepfuscht
hast hättest du längst ein neues anderes Board in deinem
Aufbau verdrahtet und wärst wieder am Laufen.

Christoph K. schrieb:
> Effekt ist aber nach wie vor derselbe. Neuer Chip läßt sich auch
> programmieren, aber Programm selbst scheint nicht zu laufen.
Hat zwar nichts mit der 5V-Verpolung zu tun, aber dieses Fehlerbild 
könnte beim Umschalten von HSI auf HSE erscheinen, wenn der Quarz nicht 
läuft.
Programmier doch mal einen Blinky mit HSI.

Christoph K. schrieb:
> Muß ich bei funktionierendem 8.000 MHz Quarz an PH0 am Chip eine Clock
> sehen?

Wenn du den Quarz Oszillator durch dein Messgerät belastest, könnte er 
dadurch anhalten.

Bei AVR konnte ich mit meinem Oszilloskop den Takt sichtbar machen, aber 
nur an XTAL2 (das würde PH1 entsprechen) und nur wenn der Tastkopf auf 
1/10 eingestellt ist. Ansonsten belastet wer den Oszillator zu stark.

Für solche Kontrollen gibt es den MCO Pin, den man per Software 
aktivieren kann. Schau dir das Clock-Tree Diagramm im Refence Manual an, 
dann siehst du, welche Taktsignale man auf den MCO Ausgang legen kann.

> Ich weiß aber nicht, was man sehen muß, wenn die MCU auf
> 168MHz eingestellt ist.

Die Frequenz des Quarz, ganz sicher keine 168 MHz.

Stefan ⛄ F. schrieb:
> Wenn du den Quarz Oszillator durch dein Messgerät belastest, könnte er
> dadurch anhalten.

Das macht er erfahrungsgemäß nicht.

> Bei AVR konnte ich mit meinem Oszilloskop den Takt sichtbar machen,

Kann man ihn auch riechen?
AVR != STM32

Christoph K. schrieb:
> Bei einem fabrikneuen mit
> Standard- Jumpersettings und der Standard-App sehe ich an R25(=PH0) die
> 8MHz.

Das ist das MCO-Signal vom F103.

m.n. schrieb:
> Das ist das MCO-Signal vom F103.
Wer weiß, welche Lötbrücken aufgetrennt wurden...

Aus dem Usermanual:
If PH0 and PH1 are used as GPIOs instead of being used as a clock, then 
SB13 and SB14 are closed and R24, R25 and R68 are removed.

•MCO from ST-LINK. From MCO of the STM32F103. This frequency cannot be 
changed, it is fixed at 8 MHz and connected to PH0-OSC_IN of the 
STM32F407VG. Configuration needed:–SB13, SB14 OPEN–R25(a) removed–R68(a) 
soldered

•Oscillator on board. From X2 crystal. For typical frequencies and its 
capacitors and resistors, refer to the STM32F407VG datasheet at 
www.st.com. Configuration needed:–SB13, SB14 OPEN–R25(a) soldered–R68(a) 
removed

•Oscillator from external PH0. From external oscillator through pin 7 of 
the P2 connector. Configuration needed:–SB13 closed–SB14 closed–R25 and 
R68 removed



Für den Blinky (mit HSE) gibt es hier ein Beispiel
https://www.mikrocontroller.net/articles/STM32F4-Discovery
Wenn das nicht geht, HSI probieren.

Und bevor kein Blinky getestet wurde, sage ich hier garnix mehr.

Jürgen S. schrieb:
> m.n. schrieb:
>> Das ist das MCO-Signal vom F103.
> Wer weiß, welche Lötbrücken aufgetrennt wurden...

Christoph K. schrieb:
> Bei einem fabrikneuen mit
> Standard- Jumpersettings und der Standard-App sehe ich an R25(=PH0) die
> 8MHz.

Alles klar?

m.n. schrieb:
> Alles klar?
Hä? Wenn interessiert, was auf dem fabrikneuen Board passiert?
> Christoph K. schrieb:
> Bei meinem funktionierenden Anwendungsboard (das mit der
> Anwendungsfirmware geladen ist) sehe ich da keine Oszillation. Bei
> meinem "reparierten" Board auch nicht.

Ich glaube, das Copy & Pasten sowie Testen eines Blinkys löst 
Kastrationsängste aus.

Jürgen S. schrieb:
> Hä? Wenn interessiert, was auf dem fabrikneuen Board passiert?

Der TO hatte danach gefragt und ich denke, zumindest er hat meine 
Antwort auch verstanden. Um Dich geht es hier nicht.

Christoph K. schrieb:
> Blinky Erfolgsmeldung kommt hoffentlich jetzt schnell.

Vielleicht geht's mit dem Code im Anhang noch etwas schneller.

Christoph K. schrieb:
> Es blinkt nichts.

Stimmt. Da muss ich nochmal "nachhaken".

Christoph K. schrieb:
> Danach wieder die Standard-App zurückgeflasht und Leds
> blinken in der gewohnten Manier.

Warum benutzt du nicht diese zum Testen deines zweiten Boards?

jo mei schrieb:
> Stimmt. Da muss ich nochmal "nachhaken".

Hier nochmal ein Testcode, der sollte aber funktionieren.

Auf die Schnelle unerklärliche Ursache: Im Debugger lief der
Code, wenn man ihn direkt ohne Debugger flashte dann nicht.

In dem Bild siehst Du den Clock Konfigurator
https://i.stack.imgur.com/gfzsT.png
Du siehst auf der linken Seite 'HSI RC' (16 MHz), das ist der interne 
Taktgeber. Und 'HSE', das ist der externe 8MHz-Quarz mit einer 
drangehängten Oszillatorschaltung.
Sowohl HSI als auch HSE können direkt als Systemtakt gewählt werden (am 
'System Clock Mux', oder über die PLL laufen. Wenn über PLL, muß 'System 
Clock Mux' auf PLLCLK eingestellt sein, und mit dem 'PLL Source Mux' 
entscheidet man, ob man die PLL mit dem HSI oder dem HSE füttert.
Die PLL multipliziert einfach Deine Eingangsfrequenz (HSI oder HSE), so 
daß Du eine ganze Bandbreite an Systemfrequenzen wählen kannst. Insofern 
brauchst Du den Quarz nicht, wenn Du HSI wählst, kannst aber trotzdem 
die PLL verwenden.

In Deinem Sourcecode steht
a) .set    PLLSRC, 1                  ; PLL clock source (0 = HSI, 1 = 
HSE)
b) .set    SW,     2              ; clock source (0 = HSI, 1 = HSE, 2 =
PLL)
c) .set    PLLM, 8

Die 3 Einstellungen brauchst Du.

a) bezieht sich dabei auf den 'PLL Source Mux'
b) auf den 'System Clock Mux'
c) auf den Eingangstakt (Quarzfrequenz HSE 8MHz bzw. Oszillator HSI 
16MHz)

PLLM ist auf 8 eingestellt, weil das Discovery einen 8MHz Quarz hat.

Du mußt nur 2 Parameter verändern, wenn Du auf HSI umschalten willst und 
über die PLL gehst:
a) .set    PLLSRC, 0                  ; PLL clock source (0 = HSI, 1 = 
HSE)
c) .set    PLLM, 16

Mit c) teilst Du eingangsseitig nicht mehr durch 8 wie bei HSE, sondern 
durch 16 wie bei HSI. Und mit a) wählst Du HSI aus. b) wird nicht 
geändert, weil der Pfad für HSI und HSE der gleiche ist.

Wenn Du das so machst, müßtest Du ungefähr die gleiche Blinkfrequenz 
sehen, ob HSE oder HSI. Wenn Du mit HSI die doppelte Blinkfrequenz sehen 
möchtest, kannst Du c) auf ".set    PLLM, 8" stehenlassen.

Ich wußte nicht, daß Du keine Entwicklungsumgebung hast bzw. dbzgl. 
unerfahren bist. Und hoffe, Du kannst Deine eigene Codevorlage mit den 
vorhandenen Mitteln und mit den Parameteränderungen compilieren.
Wenn nicht, vielleicht erbarmt sich 'jo mei' auch dazu, einen Code für 
HSI zu schreiben :)

Edit: Ab
;.set   LSE_fitted, 0              ; set to 1 if 32-KHz crystal fitted
bezieht sich Dein Quelltext auf einen anderen Quarz, den 32.768kHz-Quarz 
für die Echtzeituhr. Der Teil spielt für den Blinky keine Rolle.

Christoph K. schrieb:
> Wird der externe, an PH0/PH1 angeschlossene, 8.000 MHz  im HSI Falle
> überhaupt gebraucht?
Nein.
> Was sorgt für die Präzision der intern erzeugten 168MHz (PLL)?
Nichts. Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter 
geben.
Mit HSI dürfte die Absolutfrequenz zudem nicht sehr genau 16MHz sein, 
damit auch die PLL-Frequenz nicht genau 168MHz sein.

Mit HSI habe ich nie gearbeitet, weil bei mir auch immer ein UART in 
Aktion ist, und zur Sicherheit möchte ich dessen Baudrate quarzgenau 
einstellen können.

Jürgen S. schrieb:
>> Was sorgt für die Präzision der intern erzeugten 168MHz (PLL)?
> Nichts. Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter
> geben.

Wie bitte?
Um die PLL-Frequenz instabil zu bekommen, muß man sich schon sehr 
"bemühen". Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt.

Christoph K. schrieb:
> Oder kann ich die interne PLL mit dem externen Quarz locken?

Was denn sonst? Was bedeutet denn PLL? Soll die etwa freilaufend 
agieren?

m.n. shrieb im Beitrag #6608716:
> Wie bitte?
> Um die PLL-Frequenz instabil zu bekommen, muß man sich schon sehr
> "bemühen". Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt.
Blabber keinen Stuß. Da gabe es schon 2012 immer wieder Probleme.
Beitrag "STM32F207 Ethernet + RMII"
http://lwip.100.n7.nabble.com/Low-Iperf-performance-of-lwip-1-4-1-on-STM32-and-FreeRTOS-td21579.html
https://studio.segger.com/packages/STM32F2xx/CMSIS/Documents/DM00027213.pdf, 
Kapitel 2.8.6
Letzteres ist zwar für den F207, aber es war fraglich, ob der F407 da 
geändert wurde. Folglich hat das überhaupt nichts mit 
Abblockkondensatoren zu tun.
Ich selbst betreibe ein Board mit F4, LAN8720 und RMII mit 150MHz, da 
paßt das mit den 50MHz, die aus der PLL nach Teilen durch 3 
herauskommen. Aber viele benutzen lieber einen separaten Quarz, um nicht 
diese Probleme zu bekommen.

Es empfiehlt sich also, sinnerfassend zu lesen: Wenn ich schreibe 
"Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter geben", 
dann ist das keine generelle Aussage, sondern das Wörtchen KANN hat hier 
eine einschränkende Bedeutung. Verstanden?

Christoph K. schrieb:
> Das wundert mich sehr. Wie kriegt man denn dann physikalisch exakte
> Aussagen/Anwendungen hin, wenn die Zeitbasis nicht zuverlässig ist?
Gar nicht.

Christoph K. schrieb:
> Wie kriegt man denn dann physikalisch exakte
> Aussagen/Anwendungen hin, wenn die Zeitbasis nicht zuverlässig ist?

Gar nicht. Deswegen hat der Chip Anschlüsse für einen Quarz.

Es gibt aber Anwendungen, wo die Genauigkeit eines Quarzes nicht 
gebraucht wird.

Jürgen S. schrieb:
> Letzteres ist zwar für den F207, aber es war fraglich, ob der F407 da
> geändert wurde.

F407 != F207

> Folglich hat das überhaupt nichts mit
> Abblockkondensatoren zu tun.

Es empfiehlt sich also, sinnerfassend zu lesen: Wenn ich schreibe
"Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt.",
dann ist das keine generelle Aussage, sondern das Wörtchen VIELLEICHT 
hat hier eine einschränkende Bedeutung. Verstanden?

Jürgen S. schrieb:
> Ich selbst betreibe ein Board mit F4, LAN8720 und RMII mit 150MHz, da
> paßt das mit den 50MHz, die aus der PLL nach Teilen durch 3
> herauskommen.

Geht doch ! ;-)

m.n. schrieb:
> Es empfiehlt sich also, sinnerfassend zu lesen: Wenn ich schreibe
> "Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt.",
> dann ist das keine generelle Aussage, sondern das Wörtchen VIELLEICHT
> hat hier eine einschränkende Bedeutung. Verstanden?
Das hättest Du wohl gerne: Der Jitter im F207 (und vielleicht auch F407) 
hat mit der PLL intern zu tun und nichts mit fehlenden oder vorhandenen 
"Abblockkondensatoren". So ein Quatsch.

Christoph K. schrieb:
> War ja auch meine ursprüngliche Annahme. Nur wunderte mich jetzt die
> Aussage von Jürgen S., ich könne den Quarz weglassen.
?
Entweder bist Du ein Troll oder Du hast noch nie was von Fehleranalyse 
gehört. Dazu würde auch passen, "auf Verdacht" den F103 auszulöten. Was 
soll das bezwecken?

Ich habe überhaupt kein Interesse daran, daß Du mit dem HSI arbeitest. 
Eine Deiner Feststellungen war, daß Du ein Programm auf den F407 flashen 
kannst, das Programm dann aber nicht läuft. Aus diesem Grund ist es 
sinnvoll, zu testen, ob es an der Quarzbeschaltung liegt. Dazu ist ein 
Blinky ausreichend.
Denn: Falls der Quarz oder Deine externe Clockerzeugung/-leitungsführung 
einen Schaden hat, würde das erklären, weshalb bei dem F407, den Du mit 
5V malträtiert hattest, und bei dem neuen F407, denn Du nun draufgelötet 
hast, das Programm nicht läuft. Mit dem HSI müßte das dann gehen.
Das ist alles. Einen Blinky zu programmieren, ist weniger Aufwand, als 
einen F103 abzulöten. Keiner will, daß Du auf den Quarz verzichtest. 
Warum Du zwanghaft noch immer an den PH0/PH1 rummessen willst, anstatt 
jeweils kurz einen Blinky mit HSI und einen Blinky mit HSE 
auszuprobieren, bleibt Dein Geheimnis.
> Wenn er aber am PLL Kreis mitwirkt, wieso sehe ich keine Oszillation an
> PH0/PH1?
OMG. Was hat die PLL mit den Pins PH0/PH1 zu tun? Man sieht doch am 
Clockgenerator, daß da nichts auf PH0/PH1 zurückgeführt wird.

Christoph K. schrieb:
> Wenn PLL mit Source=HSE arbeitet, dachte ich, da eine
> Oszillation sehen zu müssen, aber wahrscheinlich fließt nur ein kleiner
> Strom quer durch den Quarz und ich sehe keinen Spannungshub.

Stefan ⛄ F. schrieb zuvor im Beitrag #6606011:
> Bei AVR konnte ich mit meinem Oszilloskop den Takt sichtbar machen, aber
> nur an XTAL2 (das würde PH1 entsprechen) und nur wenn der Tastkopf auf
> 1/10 eingestellt ist. Ansonsten belastet wer den Oszillator zu stark.

Wollte mir ja keiner glauben. Stattdessen wurde ich blöd angemacht, hier 
meine Erfahrung mit AVR einfließen zu lassen.

Christoph K. schrieb:
> Clock so
> eingestellt wie Bild.

was man auf dem Bild leider nicht sieht, ist die Einstellung ob xtal 
oder externer Clock. Das wird in Pinout Config // System Core // RCC 
ausgewählt.
Wenn hier Bypass eingestellt ist, dann muss ein externer Clock kommen, 
auf den Nucleos vom F103 wenn die Brücken original sind. Wenn die Brücke 
auf ist, dann würde das Blinky bei den modifizierten Boards nicht 
laufen.
Zum Gegentest das Blinky mit HSI bauen, das sollte dann auch bei den 
modifizierten Boards laufen.

Jürgen S. schrieb:
> Das hättest Du wohl gerne: Der Jitter im F207 (und vielleicht auch F407)
> hat mit der PLL intern zu tun und nichts mit fehlenden oder vorhandenen
> "Abblockkondensatoren". So ein Quatsch.

Es ist etwas lästig, aber damit sich hier keine Gerüchte verbreiten, muß 
ich Dir erneut widersprechen.
Ein Blick ins Datenblatt zeigt, daß die interne PLL beim F407 von VDDA 
und VSSA versorgt wird. Sofern diese Spannung nicht sehr "sauber" ist, 
wird zwangsläufig Jitter in der PLL-Regelung entstehen.
Für eine stabile PLL sind daher gerade an diesen Versorgungspins 
hinreichend Abblockkondensatoren vorzusehen.

m.n. schrieb:
> Es ist etwas lästig, aber damit sich hier keine Gerüchte verbreiten, muß
> ich Dir erneut widersprechen.
Wenn Du Dich nicht entblöden kannst, ist das Dein Problem. Du willst 
also behaupten, daß man die PLL bei Vorhandensein der 
Abblockkondenstoren, die im Datenblatt angegeben sind, für Ethernet in 
jedem Fall verwenden kann?

Dann täuschst Du Dich und andere, denn Du verbreitest Quatsch. Erstens 
hängt es davon ab, wie fehlertolerant der PHY hinsichtlich der clock 
(und hier war der DP83848 etwas zickig) ist, und zweitens, ob der PHY in 
RMII oder MII betrieben wird. RMII ist bezüglich der clock anfälliger. 
All das kann man nachlesen. Es gibt Leute, die gefiltert und abgeblockt 
haben bis zum Abwinken, die ein gutes Layout hatten, und trotzdem war 
der Jitter zu hoch.

Deine Wortklauberei, Ehrenkäsigkeit und Rechthaberei kannst Du Dir 
übrigens dorthin stecken, wo es am dunkelsten ist. Du hast es nicht 
verkraftet, daß Dein Hinweis, daß der F407 die Clock im fabrikneuen 
Board vom MCO des F103 bekommt, so notwendig war wie ein Kropf -> "Herr 
Lehrer, ich weiß was". Doof, nichts dazugelernt und das wenige 
vergessen, sagt der Lehrer zu sowas.

Johannes S. schrieb:
> Zum Gegentest das Blinky mit HSI bauen, das sollte dann auch bei den
> modifizierten Boards laufen.
Vergiss es. Das macht der nicht, denn "es müßte ja mit dem Resonator 
laufen."

Zum Glück kann man diesen bescheuerten Thread einfach links liegen 
lassen :)

Christoph K. schrieb:
> Das würde ich gerne machen, aber dazu müßte ich verstehen, warum die
> gepostete Einstellung nicht funktionieren kann.

die gepostete Einstellung ist richtig, vorausgesetzt der µC ist ok und 
es ist ein Quarz angeschlossen. Quarz ist nach deiner Beschreibung ja 
vorhanden.
Für HSI einfach den PLL Source Mux auf HSI stellen und Teiler M von 8 
auf 4 runtersetzen.

Sorry, ist noch zu früh zum Rechnen. Doppelte f bedeutet natürlich auch 
doppelt so großer Teiler, also 16 wenn es erlaubt ist.

dann würde ich sagen liegt es am schon oft diskutierten Boot0, SB18. 
Wenn der offen ist, dann läuft der nach dem Start in den Bootloader und 
nicht in dein Blinky.

das ist bei den Discos anders, die haben ihren eigenen Quarz, wurde 
schon geklärt.

Faszinierend finde ich, dass hier immer noch modifizierte Boards 
diskutiert wird, ohne die Modifikationen zu kennen. Das Thema läuft ja 
schon länger, nicht erst seit 26. Februar.

Da muss ich mich schon fragen, ob das ganze mutwillige Trollerei ist 
oder ob hier jemand wirklich ein Problem lösen will.

Christoph K. schrieb:
> Ich habe die Modifikationen hier in diesem Thread schon lange gepostet.

In kaum nachvollziehbarer Form. Vor allem weil du die ganze Zeit vom HSE 
Oszillator und Quarz geschrieben hast, ohne einen Quarz eingesetzt zu 
haben. Da passen schon deine eigenen Infos nicht zusammen.

Ein Schaltplan wäre hier wesentlich hilfreicher.

Christoph K. schrieb:
> Schaltplan ist der aus dem ST UM1472 mit den beschriebenen Mods.

Soll ich mit den jetzt ausdrucken und dann die Textuellen Anmerkungen 
einzeichnen? Was mit dem Quarz ist (um den sich hier alles dreht), weiß 
ich dann immer noch nicht.

Abgesehen davon: Das ist deine Hausaufgabe.

> Ich habe die Clockkonfiguration der
> Anwendung gepostet. Die ist HSE/PLL.

Ohne Quarz, ohne Bypass -> Kann nicht funktionieren. Gehen sie zurück 
aus Los.

Stefan ⛄ F. schrieb:
> Ohne Quarz -> Kann nicht funktionieren.

du nervst und müllst den Thread voll. Das Disco1 hat einen Quarz. Und 
trotzdem wird gerade erstmal HSI getestet.

Habe hier gerade an einem F411 Blackpill getestet, wenn ich Boot0 auf 
high halte kann ich auch nicht debuggen.
Das Disco hat den Boot0 rausgeführt, Brücke nach GND dran und probieren, 
nicht wieder neuen Nebenkriegsschauplatz aufmachen.
-> ok, geklärt.

nächster Schritt wäre dann wieder mit HSE (evtl. erst ohne PLL). Aber 
vermutlich war dann auch hier Boot0 das 'Problem'.

Johannes S. schrieb:
> Das Disco1 hat einen Quarz.

Kritik angenommen, ich habe es mit den Nucleo Board verwechselt.

dann würde ich den verdächtigen USART in das Blinky einbauen und da 
etwas ausgeben. Geht für einen quick&dirty Test auch einfach mit CubeMX.
Beim Umlöten der Chips könnte da auch eine Verbindung Chip-Header kaputt 
sein.