STM32: Flashen geht; uC stoppt sofort. Takt-Hygiene?

Nils schrieb:

Mein Verdacht ist, dass die Taktsignale zu verwaschen sind und der uC deswegen keinen gültigen Takt hat.

Unsinn. Das Programm schaltet die LED ein, mehr macht dein Programm nicht mit dem LED Pin. Mit anderen Worten dein Programm macht genau das was du programmiert hast. Das ist vermutlich aber nicht das was du willst.

Das ist das schöne an Arduino - da kann man einfach ein mitgeliefertes Example Sketch testen und weiß dann das funktioniert auch.

Nils schrieb:

Mein Verdacht ist, dass die Taktsignale zu verwaschen sind und der uC deswegen keinen gültigen Takt hat.

Nö, mein Verdacht ist, dass du keine ausreichend gute Masseverbindung zum Oszilloskop hergestellt hast.

Nils schrieb:

Oder jedenfalls stoppt das Programm sehr schnell.

Woran erkennst du das? Aus deiner Programmierung (Programmcode) lässt sich das jedenfalls nicht schliessen.

Nils schrieb:

Ich war der Meinung, bei der Auslegung speziell der Leitungen zum Quartz die gängigen Kriterien ziemlich gut getroffen zu haben.

Ja, sogar päpstlicher als der Papst.

Nils schrieb:

Aber schon das Signal von HSE ist nicht wirklich ein sauberer Puls

Doch, völlig ausreichend.

Nils schrieb:

variiert aber nur um 1,7V herum

Das ist vermutlich der eingeschränkten Bandbreite deines Oszilloskops oder deines Tastkopfs zuzuschreiben.

Nils schrieb:

was ich evtl. wegen Brett-vorm-Kopf nicht sehe?

Naja, dein Programm eben ... da sehe ich das Brett, wie Thomas Z schon schrub.

Nils schrieb:

erkläre ich mir damit, dass beim Flashen der Takt vom ST-Link2 kommt(?)

Der ST-Link liefert dem Prozessor keinen Takt, der wird nur zum Hineintakten der Programmier-/Flash-Abläufe gebraucht.

Nils schrieb:

Falls es am Takt liegt

Nö.

Nils schrieb:

Sind die Kondensatoren am Quartz (CL=10pF) falsch berechnet?

Nö, passt schon, kannst später evtl. etwas grösser machen.

Probleme mit dem Taktsignal kann man leicht ausschließen, indem man probeweise mal den internen Oszillator (HSI) benutzt.

Auf genau so eine Antwort hatte ich gehofft :-)

Das mit dem Toggle in der Schleife war genau hinter dem erwähnten Brett gelegen. Die beiden WritePIN-Zeilen mussten natürlich vor die Schleife, damit die LEDs schön im Sekundentakt wechseln. Genau das tun sie jetzt auch, bei jeder eingestellten HCLK bis zur Obergrenze (180MHz).

Beim Oszi muss ich zugeben, dass ich ein absoluter Gelegenheitsnutzer bin, reiner Hobby-Bastler. Hier hatte ich die Masseklemme benutzt, die man unten am Tastkopf anclipst, mit 10cm Litze. Besser wäre vermutlich eine deutlich kürzere und weniger antennenartige Masse-Verbindung gewesen (wie die kleine Drahtklemme, die man oben auf den Tastkopf klemmt)? Das Oszi wirbt mit einer Bandbreite von 200MHz (HDS2202S).

Der Tastkopf stand auf 10x, war das hier falsch? Falls ja, gibt's da ne Faustregel, wann 1x und wann 10x?

Auf jeden Fall eine wertvolle Erkenntnis, dass nicht das gemessene Signal, sondern meine Messung Mist war. Und natürlich der Test-Code.

Interessehalber: Wären alle Clock-Signale bei vernünftiger Messung saubere Rechteck-Pulse, auch in der Praxis? Oder könnte man da sonst anhand von verschliffenen Flanken oder falschen Pegeln eindeutige Rückschlüsse auf spezifische Fehler in der Auslegung ziehen (und welche)?

Danke in die Runde!

Nils schrieb:

Wären alle Clock-Signale bei vernünftiger Messung saubere Rechteck-Pulse, auch in der Praxis?

Bei ein paar hundert kHz ja, aber nicht mehr bei einigen MHz. Denn die Kapazitäten der Leitungen und angeschlossenen Bauteile beeinflussen die Signalform deutlich.

Ein Taktsignal muss auch gar nicht rechteckig sein. Hauptsache, die Wechsel zwischen Low und High sind eindeutig und einigermaßen regelmäßig. Theoretisch müsste sogar ein Sinus Signal gut genug sein (ausprobiert habe ich es nicht).

Nemopuk schrieb:

Ein Taktsignal muss auch gar nicht rechteckig sein.

Muss es schon, zumindest näherungsweise. Es gibt i.d.R. Mindestforderungen bzgl. der "Steilheit" der Flanken.

Allerdings gilt das natürlich nur für die Stelle(n) wo der Takt tatsächlich als solcher, also zum Betrieb irgendwelches digitalen Solms verwendet wird. Nicht aber notwendigerweise für die Stelle, an der er ursprünglich erzeugt wird. Klassisches Beispiel natürlich: Der Quarz in einer Oszillatorschaltung.

An den kommt man ja oft direkt ran und natürlich hat man hier kein Rechtecksignal, sondern einen ziemlich guten Sinus. Jedenfalls, wenn Oszillatorschaltung korrekt ausgelegt ist.

Aber "hinter" der Oszillatorschaltung gibt es dann einen Buffer, der aus diesem Sinus ein korrektes Rechteck mit hinreichend steilen Flanken erzeugt. Und erst das wird tatsächlich als "Antrieb" für die Digitalschaltung verwendet.

Hippelhaxe schrieb:

...die Klüsen aufmacht.

Ist das so ein Krabbenbrötchen-Ausdruck?

Hey ho Perfekt, dass du alles mitgeliefert hast, wäre es doch nur immer so ;) Hinweis 1: Im Schaltplan ist C20 verpolt drinn. Hinweis 2: Die ganzen BATT_Vxx gehen auf ADC, korrekt? ich würde da evtl. noch ein kleines C spenden, da der Spannungsteiler doch recht hochohmig ist. Der ADC braucht auch minimal Strom und mit den grossen Impedanzen kann es das Signal verziehen. (OK, wieviel es wirklich ausmacht weiss ich nicht, aber Wissen schadet nie...)

Cyblord -. schrieb:

Hippelhaxe schrieb:

...die Klüsen aufmacht.

Ist das so ein Krabbenbrötchen-Ausdruck?

Vorwiegend, ja. Aber nicht nur.

Schließlich gibt's auch da, wo sich alle sehr DEUTSCH fühlen, aber kaum jemand deutsch sprechen kann (oder es zumindest normalerweise nicht tut), eine Binnenschifffahrt. Da sind die Klüsen nur kleiner als bei den richtigen Schiffen, es gibt sie aber auch dort.

Was mir im Schaltplan noch auffällt ist dass der Widerstand zwischen HSE_OUt und dem Quarz fehlt. Daher besteht die Gefahr dass Du den Quarz überlastest.

Wert kann man mit den Detail-Parametern des Quarzes rechnen oder auch den Strom messen. Lohnt aber für kleine Stückzahlen nicht. Da würde ich 1k nehmen und gut ist. Bei Bedarf kann man das dann immer noch anpassen.