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

[Nils (nilsb)]

Moin,

Mein STM32F446 lässt sich per CubeIDE flashen, läuft anschließend aber 
nicht an. Oder jedenfalls stoppt das Programm sehr schnell. Aktuell 
lasse ich in main() nur LEDs blinken, zu Testzwecken. Es geht auch eine 
an, aber in dem Zustand bleibt der uC dann. D.h. diese eine LED leuchtet 
weiter, sonst passiert nix, und in diesem Zustand habe ich die beiden 
angehängten Oszi-Schriebe an MCO2 aufgenommen.

Mein Verdacht ist, dass die Taktsignale zu verwaschen sind und der uC 
deswegen keinen gültigen Takt hat. Dass er sich überhaupt flashen lässt 
(jedesmal, ohne Probleme), erkläre ich mir damit, dass beim Flashen der 
Takt vom ST-Link2 kommt(?).

Schaltplan und Platine hängen an. Ich war der Meinung, bei der Auslegung 
speziell der Leitungen zum Quartz die gängigen Kriterien ziemlich gut 
getroffen zu haben. Aber schon das Signal von HSE ist nicht wirklich ein 
sauberer Puls (was es vermutlich idealerweise sein sollte?), und PLLCLK 
hat zwar die richtige Frequenz, variiert aber nur um 1,7V herum, 
+/-0,6V. In beiden angehängten Oszi-Schrieben sind die X- und Y-Skala 
identisch, und der gelbe Marker links unten markiert 0V. Das Oszi hat 
mit beiden Signalen keine Probleme, sie sauber zu triggern, und sie 
stehen stabil ohne sichtbares Flackern.

1. Ist das Taktsignal hier tatsächlich das Problem, (und/)oder fällt 
hier jemandem was ganz anderes auf, was ich evtl. wegen Brett-vorm-Kopf 
nicht sehe?
2. Falls es am Takt liegt: Wie bekomme ich den sauberer? Die Leitungen 
zum Quartz sind kurz und haben zumindest grob die gleiche Länge. Sind 
die Kondensatoren am Quartz (CL=10pF) falsch berechnet?

Besten Dank für sachdienliche Hinweise...

Nils

[Thomas Z. (usbman)]

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.

[Alexander (alecxs)]

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

[Michael F. (Firma: IAR Systems) (michael_iar)]

Moin,

wenn Du LEDs blinken lassen möchtest, dann wäre eventuell 
HAL_GPIO_TogglePin anstelle von HAL_GPIO_WritePin die Funktion der 
Wahl...

Gruß,
Michael

[Wastl (hartundweichware)]

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.

[Nemopuk (nemopuk)]

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

[Hippelhaxe (hippelhaxe)]

Nemopuk schrieb:

> Probleme mit dem Taktsignal kann man leicht ausschließen,
> indem man

...die Klüsen aufmacht.

Die Oszillogramme sehen im Rahmen der eingeschränkten
Möglichkeiten -- Oszi-Typ? Unbekannt. Tastkopftyp?
Unbekannt. Grenzfrequenz? WAS IST DAS??? Kapazitive
Belastung? NIE GEHÖRT...-- perfekt aus.

Ich lehne mich mal aus dem Fenster und wage eine
abenteuerliche Prognose: Am Takt liegt's nicht :)

[Nils (nilsb)]

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!

[Nemopuk (nemopuk)]

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

[Marci W. (marci_w)]

Hallo Nils,

hmmm, Dein Programm sieht seltsam aus:

Zeile 1: Du schaltest einen Pin ein
Zeile 2: Du schaltest einen anderen Pin aus
Zeile 3: Du wartest 1s

Also müsste bei korrektem Verhalten die LED an "TEST1_Pin" eingeschaltet 
werden und das auch bleiben. Es tut sich sonst nämlich nichts mehr.

Blinken:
wiederhole für immer:

- LED einschalten (SET)

- warten

- LED ausschalten (RESET)

- warten

Oder:

- LED toggeln

- warten

ciao

Marci

[Ob S. (Firma: 1984now) (observer)]

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.

[Cyblord -. (cyblord)]

Hippelhaxe schrieb:
> ...die Klüsen aufmacht.

Ist das so ein Krabbenbrötchen-Ausdruck?

[Simi S. (kokoianer)]

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

[Ob S. (Firma: 1984now) (observer)]

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.

[Hippelhaxe (hippelhaxe)]

Nils schrieb:

> Beim Oszi muss ich zugeben, dass ich ein absoluter
> Gelegenheitsnutzer bin, reiner Hobby-Bastler.

Kein Problem; niemand kommt allwissend auf die Welt.


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

Klar, kurze Stippen sind besser als lange.

Andererseits ist es auch kein Verbrechen, die normale
Masseklemme zu benutzen, wenn man nur mal gucken will,
ob überhaupt Takt da ist.

Man sollte aber generell ALLE Oszillogramme mit einer
gewissen Skepsis betrachten und nix blind glauben;
Rückwirkungen und Messfehler entstehen schneller, als
man denkt.


> Das Oszi wirbt mit einer Bandbreite von 200MHz
> (HDS2202S).

Ah okay. Das ist in Ordnung.

(Wäre nur nett gewesen, wenn Du das gleich im Ursprungs-
beitrag geschrieben hättest... ich habe Deine Screenshots
in Pinkertonsche Planquadrate eingeteilt und abgesucht,
ob ich irgend einen Hinweis auf Oszi-Typ oder Bandbreite
finde...)


> Der Tastkopf stand auf 10x, war das hier falsch?

Nein; alles in Ordnung.


> Falls ja, gibt's da ne Faustregel, wann 1x und wann 10x?

Naja, wenn ausreichend Signalpegel vorhanden ist -- wie
bei digitalem Kram üblich -- ist man mit 10x immer auf
der sicheren Seite.

Außer "Signal wird zu klein" gibt es m.E. keinen echten
Grund, auf 1x zu schalten.

Insofern hast Du alles richtig gemacht.


> Auf jeden Fall eine wertvolle Erkenntnis, dass nicht
> das gemessene Signal, sondern meine Messung Mist war.

Och nö... das ist zu hart ausgedrückt.

Die 16MHz sollten eigentlich etwas besser aussehen, aber
das ist Ningeln auf hohem Niveau. Da müsste man erstmal
mit kurzer Massestrippe messen und evtl. die Tastkopf-
kompensation korrekt einstellen.

Die 84MHz werden schlicht durch Innenwiderstand des µC
und Tastkopfkapazität verzerrt werden, nehme ich an.
Müsste man genauer prüfen, wenn's einen interessiert.

Ansonsten liegt Deine Messung für quick&dirty im
erwarteten Rahmen.


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

Bei so einer Gelegenheitsmessung wie Deiner: Nee,
nicht zwingend -- und nicht bei Frequenzen jenseits
von 10MHz...

Es gibt einfach zu viele Einflussgrößen, die man
nicht kennt. Das ist völlig normal.

Man kann nicht erwarten, dass bei einer ad-hoc-Messung
im Labor die Oszillogramme wie aus dem Lehrbuch
aussehen.


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

Naja, EINDEUTIGE Rückschlüsse werden die Ausnahme sein,
aber man kommt schon allmählich schneller zu einem
begründeten Verdacht, woran es hängt.
Erfahrung und Hintergrundwissen sind wichtig; ist beides
vorhanden, macht gute Messtechnik auch das Leben leichter.

[Gerd E. (robberknight)]

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.