Moin,
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?
Gruß,
Nils
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 ...
Andreas hat es schon erwähnt.
Andreas B. schrieb:> Erstens vermisse ich den Anschluss von Pin 32.
Ich fürchte der Chip wird ohne Versorgung durch Pin 32 nicht
korrekt funktionieren. Ist zwar "nur" Masse, aber wichtig.
So "unwichtig" wie Abblock-Kondensatoren. Ich hoffe du hast
sie "drauf".
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.
Nils schrieb:> 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.
Wastl schrieb:> 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.
Nils schrieb:> 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.
Nils schrieb:
Gregor J. schrieb:> Ist hier ein Quarz oder ein Oszillator gemeint?
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!
Harry L. schrieb:> 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 ;)
Bauform B. schrieb:> 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.
Bauform B. schrieb:> 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.
Gregor J. schrieb:> Bauform B. schrieb:>> 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!
Nils schrieb:> 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.
Thread beobachten
Seitenaufteilung abschalten