Ich versuche, eine Platine mit einem STM32F030K6T6 in Betrieb zu nehmen, Schaltung siehe Anhang. An HW habe ich in CubeIDE außer dem SWD, mit dem ich flashe, erstmal nur den externen Oszillator und zwei Test-LEDs konfiguriert.
Mit dem internen Oszillator HSI (8MHz) oder dem externen HSE (8MHz-Quarz) als ausgewählte Taktquelle und PRESCALER=1, also HCLK=8MHz, läßt sich die Software flashen.
Sobald ich aber irgendeine Frequenz per PLL erzeuge, egal ob mit HSI oder HSE als dessen Quelle, bekomme ich diese Fehlermeldungen beim Download (Log hängt an):
File download complete
Time elapsed during download operation: 00:00:00.483
Verifying ...
Download verified successfully
Target is not responding, retrying...
Target is not responding, retrying...
Shutting down...
Could not halt device (19)
Target is not responding, retrying...
Danach ist es schwierig, den uC überhaupt wieder anzusprechen und wieder mit der alten Konfiguration zu beschreiben. Teils erkennt CubeIDE überhaupt kein Ziel mehr, teils wird mit generischen Meldungen abgebrochen ("check cabling and power" u.ä.).
Zu dieser Fehlermeldung "Could not halt device (19)" habe ich im Internetz keine verwendbaren Lösungsansätze gefunden. Einmal wurde empfohlen, das USB-Kabel zum ST-Link2 kurz zu halten und keinen USB-Hub zu verwenden (getestet, keine Änderung), ein anderer Beitrag war eine Übersetzung aus dem chinesischen: "You may need to check the code problem. It may be that some IO ports have serious conflicts." Also ebenfalls nicht hilfreich.
Mein einziger User-Code ist bisher dieser hier in main(), um die LEDs anzusteuern, alles andere ist der von CubeIDE generierte Code, basierend auf Pin- und Clock-Konfiguration. Bei allen funktionierenden Downloads (HSI oder HSE ohne PLL) sehe ich anschließend LED1 konstant leuchten und LED2 mit einer Periode von 1s blinken. Die Periode stimmt auch noch, wenn ich HSI oder HSE noch durch den Prescaler auf z.B. 1MHz reduziere.
Ich benutze ein ST-Link2, abgetrennt von einem Nucleo-Board und mit neuester Firmware. Habe aber auch ein anderes ST-Link2 mit älterer Firmware und ein ST-Link2-Dongle getestet, das Verhalten ist mit allen Varianten gleich.
Die CubeIDE-Installation funktioniert ansonsten tadellos, z.B. für diverse Bluepills und Blackpills. In der "Run Configuration" für dieses Projekt habe ich außer dem standardmäßigen "Connect under reset" auch alle anderen Optionen aus dem entsprechenden Dropdown-Menü durchprobiert. Das ändert aber am Problem nichts.
Kann jemand was mit dieser Fehlermeldung anfangen oder sonstige sachdienliche Hinweise geben?
Erstens vermisse ich den Anschluss von Pin 32. Zweitens wäre es sinnvoll, den Systemtakt bzw. PLL-Takt an MCO (PA8) ausgeben zu lassen und dort zu messen. Nicht dass CubeMX da irgendwelchen Murks macht ...
Ich habe mal wie vorgeschlagen RCC_MCO auf PA8 ausgegeben. Reiner Zufall, daß ich gerade diesen Pin als Testpin im Design habe :-)
Mein Oszi zeigt dort stabile 8Mhz an, wenn ich HSE oder HSI mit 8MHz ohne Prescaler ausgewählt habe. Dann habe ich mal versucht, 4MHz per PLL aus HSI zu erzeugen. Dabei geht PA8 auf Null und es tut sich dort gar nichts mehr. Die Fehler sind dann die gleichen wie oben beschrieben.
Pin32 geht bei mir auf GND. Keine Ahnung, warum der im Schaltplan nicht auftaucht, aber im PCB-Editor war er da und ist auf der Platine mit GND verbunden. Auch die Abblock-Kondensatoren mit 100nF sind da, einer direkt beim Pin1 und einer beim Pin17.
Pin32 geht bei mir auf GND. Keine Ahnung, warum der im Schaltplan nicht
auftaucht, aber im PCB-Editor war er da und ist auf der Platine mit GND
verbunden.
Da hat wohl jemand beim Anlegen des Schaltplansymbols diese bescheuerte Pin-Stapelei betrieben und Pin 16 sowie Pin 32 mit nur einem VSS Pin im Symbol beglückt.
Das ist zwar technisch möglich, sollte man aber niemals machen, eben genau deshalb, weil es zu Verwirrung führt, weil man nur einen Pin verbunden sieht.
Poste doch mal dein *.ioc File mit dem das Flashen
nicht funktioniert.
Oh, stimmt, das ist vielleicht besser als nur die Screenshots.
Ich hab mal die Version angehängt, die ich vorhin probiert hatte, um die eventuell sich ändernde SYSCLK mit dem Oszi zu messen.
Nach dem Fehlversuch habe ich ewig gebraucht, um den dann erstmal leblosen Chip wieder ansprechen zu können. Das scheint mir ein eher zufälliger Prozess zu sein, jedenfalls habe ich keine Kombination aus
uC resetten
ST-LINK resetten (=USB raus und rein)
Flash-Versuch mit zunächst manuell gehaltenem Reset und loslassen kurz nachdem das Flashtool das Warten auf die Verbindung meldet (klappt für sich genommen nicht, aber manchmal klappte danach ein normales Flashen)
und normalem Flashen gefunden, die das Ding mit der alten Config zuverlässig wieder ansprechbar macht. Stattdessen bringt das Flashtool diverse Fehler, häufig einfach "Kein STM-Target gefunden", "check cabling", "Device not halted" oder "No connection to ST-Link". Nach gefühlt dutzenden Versuchen in allen Reihenfolge-Variationen hat dann irgendwann ein Flash-Vorgang wieder funktioniert. War vermutlich einfach Zufall...
Außerdem noch als Nachtrag die SYSCLK auf dem Oszi nach dem Vorschlag von Andreas. Ob die Signalform so aussehen muß, weiß ich nicht, aber die Frequenz ist stabil 8MHz, was ich mal als akzeptabel bewertet hatte.
An HW habe ich in CubeIDE außer dem SWD, mit dem
ich flashe, erstmal nur den externen Oszillator und zwei Test-LEDs
konfiguriert.
Ist hier ein Quarz oder ein Oszillator gemeint? Denn es sind zwei verschiedene Dinge. Wie auch immer, Du solltest auf jeden Fall den ganzen Aufbau und kompletten Code zeigen – Code als Anhang, weil der automatisch erzeugte Code ziemlich lang ist. Bei NRST verwende ich grundsätzlich immer einen 10k-Pull-UP – Du kannst ausprobieren, ob es irgendetwas am Verhalten Deiner Schaltung ändert. Das Design und der Aufbau müssen solide sein – an VDDA und VSSA gehören z.B. auch zwei Abblockkondensatoren (1µF+10nF), weil damit u.a. auch die PLL gespeist wird – es geht also nicht nur um den ADC, sondern um den ganzen Block mit analoger Peripherie. Im Anhang ein Schaltplan von mir und ein Auszug aus dem Datenblatt zum Power-Supply-Scheme, wo das explizit zu sehen ist. Alle VDD- bzw. VSS-Pins müssen auch real auf der Platine elektrisch niederohmig hart untereinander verbunden sein, selbst dann, wenn intern im Chip manchmal eine 1-3Ω-Schutzverbindung existiert. Solche Probleme mit der PLL, wie Du sie schilderst, hatte ich noch nie mit irgendeinem STM32, bei F030 hatte ich allerdings bis jetzt nur den CC im Einsatz, die K6 und F4 warten noch in der Schublade für deren Einsatz – der Kerninhalt dürfte bei K6 und CC aber quasi gleich sein. Bei der Erstbeschreibung eines fabrikneuen F030CC gab es mal einen Hänger, aber nach dem Abstecken der Versorgungsspannung war das anschließend nie wieder passiert und hat meiner Meinung nach auch nichts mit der PLL zu tun gehabt. Beim schnellen Blick in die Errata habe ich nichts im Kontext des geschilderten PLL-Problems gefunden.
Als Erstes solltest du im CubeMX im PLL-Source Mux auf HSE schalten!
Nach jeder Änderung einmal ggf den Button Resolve Clock Issues anklicken!
Wenn du HCLK änderst geschieht das i.d.R. automatisch - und passt dann auch.
Und noch Eins:
Das hat zwar nix mit deinem konkreten Problem zu tun, aber du solltest dir dringend angewöhnen, die Pins mit korrekten Bezeichnungen zu versehen.
Dazu rechts-Klick auf den Pin und "Enter User-Label"
Diese Labels kannst du dann auch in deinem Code nutzen, der dadurch deutlich lesbarer wird.
Sorry, HSE ist ein externer 8MHz-Quarz auf meiner Platine.
Aufbau müssen solide sein – an VDDA und VSSA gehören z.B. auch zwei
Abblockkondensatoren (1µF+10nF), weil damit u.a. auch die PLL gespeist
wird – es geht also nicht nur um den ADC, sondern um den ganzen Block
mit analoger Peripherie. Im Anhang ein Schaltplan von mir und ein Auszug
aus dem Datenblatt zum Power-Supply-Scheme, wo das explizit zu sehen
ist.
Da könntest du die Lösung geliefert haben. Ich wusste nicht, daß die PLL ausgerechnet von VDDA gespeist wird, aber du hast Recht, das geht tatsächlich aus dem RefManual hervor. Die Schaltung für VDDA hatte ich schon so ähnlich vorgesehen, wie ich auch deine Hinweise verstehe, links oben in meinem Plan, inklusive der Anordnung nahe den Pins. Allerdings sind just diese Teile (C7, C10, C11, FB1) auf meiner Platine nicht bestückt. Vermutlich hatte JLCPCB die gerade nicht parat und ich habe das beim Bestätigen der Stückliste übersehen. Außer FB1 (FerriteBead), da war das Absicht, weil ich die Dinger noch hier rumfliegen habe.
Da der ADC für meine Anwendung nicht zentral ist, hatte ich das erstmal ignoriert. Aber nach deinem Hinweis tippe ich jetzt stark darauf, daß ganz einfach die PLL nicht mit Strom versorgt wird. [Kopf-->Tischplatte].
Werde ich morgen genauer anschauen und (falls ich passende Kondensatoren da habe) ggf. als gelöst zurückmelden... Für heute bin ich durch :-)
Danke schonmal, auch an die anderen Helfer!
Als Erstes solltest du im CubeMX im PLL-Source Mux auf HSE schalten!
Sorry, falls ich das nicht erwähnt hatte: Weder HSI noch HSE als Source für PLL funktionieren, ich hatte beides ausprobiert.
Aber ich denke, Gregor hat schon den entscheidenden Hinweis geliefert: Weil einige Bauteile auf der Platine (noch) nicht bestückt sind, hat wohl einfach die PLL keinen Strom. Ich hatte fälschlich gedacht, diese Bauteile (noch) nicht zu brauchen, siehe voheriger Beitrag.
Hier noch zwei Fotos von meiner Platine – die Abblockkondensatoren für VDDA sind bei mir aus Platzgründen – und weil ich VDDA auf die Stiftleiste herausgeführt habe – ca. 1-1,5cm vom Chip entfernt, es funktioniert aber trotzdem tadellos. Hier sehe ich auch auf den Fotos, dass ich den STM32F030K6T6 vor einigen Jahren bereits doch verlötet habe – und dieser Chip demnach alle meine Tests durchlaufen und bestens bestanden hat, incl. PLL-Funktion mit Vervielfachung von 8 auf 48MHz – ich habe jetzt nur die Platine mit dem F334K8 gefunden, aber falls nötig, werde ich die Platine mit dem F030K6 auf dem Foto bei mir suchen. Gemacht wird es mit der STM32CubeIDE und meinem ST-Link-V2.1, der dem auf den älteren Nucleoboards gleicht.
Schön, dass es doch noch eine vernünftige Erklärung gab. Aber wie kann das überhaupt passieren? Man schaltet doch den Systemtakt erst um, wenn die Hardware ein PLL-Ready-Bit (o.ä.) gesetzt hat?
Ja, die falsche Taktfrequenz ist dann auch nicht offensichtlich, aber doch nicht so chaotisch. MCO ist ja der letzte Pin, den man für anderes benutzt ;)
Schön, dass es doch noch eine vernünftige Erklärung gab.
Das wissen wir noch nicht, das wird der Autor noch bestätigen müssen, um das so eindeutig sagen zu können – VDDA gar nicht mit Strom zu versorgen wäre jedenfalls eine mögliche Erklärung für ein unvorhergesehenes Verhalten dieser Art, da bei STM32 sehr viele Innereien darüber versorgt werden, der ADC ist nur die Spitze des Eisbergs. Unter Umständen kann bei so etwas auch der Chip kaputtgehen, denn es wird in den Datenblättern erklärt, dass man z.B. auch Spannungsrampen beim Power-Up und -Down explizit einhalten muss, falls VDDA nicht mit VDD zusammengeschaltet wird, und die Differenz zwischen den beiden Spannungsschienen darf dann auch nicht allzu groß sein bzw. eine bestimmte Bedingung eingehalten werden. Bei den AVRs (z.B. ATMEGAs) sollte man so eine Nummer mit AVCC auch nicht machen – manche machen es trotzdem und wundern sich dann.
Schön, dass es doch noch eine vernünftige Erklärung gab. Aber wie kann
das überhaupt passieren? Man schaltet doch den Systemtakt erst um, wenn
die Hardware ein PLL-Ready-Bit (o.ä.) gesetzt hat?
Ähm, wenn die PLL über VDDA versorgt wird, dürfte die Logik, die das Einrasten der PLL feststellt, auch darüber versorgt werden ... und dass das Status-Bit dann eventuell Unfug anzeigt, wär' nicht sooo überraschend.
Schön, dass es doch noch eine vernünftige Erklärung gab.
Das wissen wir noch nicht, das wird der Autor noch bestätigen müssen, um
das so eindeutig sagen zu können – VDDA gar nicht mit Strom zu versorgen
wäre jedenfalls eine mögliche Erklärung für ein unvorhergesehenes
Verhalten dieser Art, da bei STM32 sehr viele Innereien darüber versorgt
werden, der ADC ist nur die Spitze des Eisbergs. Unter Umständen kann
bei so etwas auch der Chip kaputtgehen, denn es wird in den
Moin moin,
Also ich habe die beiden fehlenden 1uF-Kondensatoren C7 und C10 und den Ferritkern FB1 ergänzt. C11 (10nF) war doch schon bestückt. Jetzt hat also VDDA also die vorgesehene Versorgung.
Und jetzt funktioniert PLL ganz normal, d.h. ich kann beliebige Frequenzen bis 48MHz aus HSI oder HSE erzeugen.
Auch den ADC habe ich jetzt aktiviert (PA0), und der Chip lässt sich tadellos beschreiben. Offenbar habe ich ihn also auch nicht durch "VDDA<<VDD" zerlegt, was das Datenblatt ja eigentlich verbietet.
Der entscheidenden Hinweis war, daß PLL von VDDA versorgt wird. Was ich mir jetzt hoffentlich merken kann. Es hätte natürlich auch geholfen, wenn ich die Platine vor der Inbetriebnahme erstmal fertig bestückt hätte. Dann wäre PLL versorgt gewesen, aber der Lerneffekt war ja auch nicht schlecht :-)
Vielen Dank an alle, die reingeschaut haben, insbesondere Gregor!
Vielen Dank an alle, die reingeschaut haben, insbesondere Gregor!
Ich bedanke mich ebenfalls, weil das indirekt manchmal auch für mich ein Erkenntnisgewinn ist, denn durch mein angesammeltes Wissen und meine jahrzehntelange Erfahrung wäre ich z.B. niemals auf die Idee gekommen, einen STM32 so ohne VDDA zu betreiben. Ich vollführe hin und wieder mal Zerstörungstests, diese beziehen sich in der Regel auf lineare Spannungsregler (Schaltregler sind in letzter Zeit auch dazugekommen). Bei µControllern mache ich manchmal auch diverse Tests, um zu schauen, was z.B. die Portausgänge aushalten bzw. wie sie sich verhalten – ATMEGAs konnten z.B. kurzzeitige Kurzschlüsse und Pinkonflikte überstehen, bei 5V kam ich nachweislich, weil damals gemessen, auf maximal 83mA als Kurzschlussstrom; wie gesagt, nur 1-2 Sekunden, danach waren die Pins aber weiter intakt oder zumindest von außen nicht feststellbar beschädigt, wie das auf Siliziumebene danach dort aussieht, weiß man ohne Öffnen und Mikroskop leider nicht. Bei STM32 bin ich nur kontrolliert (ohmsche Last) bis ca. 25-27mA mit dem Pinstrom hochgegangen, weil mir zu diesem Zeitpunkt der µC samt Board dafür zu schade war – dem Datenblatt nach sollte er das aushalten und das war auch wirklich so. Bei ST nimmt man solche Angaben im Datenblatt ernst, bei vielen unseriösen Herstellern ist das oft nur schöne Produktwerbung, was da im Datenblatt zusammengedichtet steht; oft steht auch mal überhaupt nichts in deren Datenblättern, weil sie sich nicht einmal selbst die Mühe machen, das zu testen, zu dokumentieren und diese Information dem Kunden zur Verfügung zu stellen. Einen STM32 habe ich auch mal versehentlich einige Sekunden mit ca. 4,3V betrieben – welcher es war, weiß ich nicht mehr, vermutlich ein F334 oder G441 – er hat es aber definitiv überlebt und ich vermute mal, dass er das auch kurzzeitig bei 5V tun würde, für einen aussagekräftigen Zerstörungstest sind mir die Teile aber zu teuer und außerdem kann das immer (und wird) auch mit dem Herstellungsprozess variieren, insofern würde so eine Erkenntnis nur für die Charge(n) aus der jeweiligen Fabrik gelten, die man getestet hatte.
Übrigens, den Einkauf auf Aliexpress & Co. von Halbleitern, die besonders leicht nachgebaut und gefälscht werden können, insbesondere Spannungsreglern, Transistoren etc, kann ich jedem abraten – ich habe mir als Erinnerung einige Stangen an LM317 in TO220 eingelagert, die ab ca. 20-22V Eingangsspannung (Ausgang auf VRef mit 1,25V) einen irreversiblen Durchbruch erleiden (Kurzschluss). Die Originalteile von STM bestanden damals meinen Zerstörungstest bis ca. 43V, obwohl die absolute Grenze im Datenblatt damit schon überschritten wurde. Die Fälschung war hier aber auch schon am Design und Schriftzug erkennbar.
schematic.png
(360 KB)
HW_CubeIDE.png
(32 KB)
Clocks_without_PLL.png
(130 KB)
Clocks_with_PLL.png
(41 KB)
