(Scherz jetzt, obwohl mich mein Problem schier umbringt) Da sagt noch einmal jemand etwas gegen ein Steckbrett: Nachdem ich eine Schaltung, die auf dem Steckbrett super läuft, als PCB geroutet und bestückt habe, läuft die Schaltung auf der Platine nicht.
Für alle die mich (mal wieder) anstänkern wollen: Ich suche den Fehler ganz klar bei mir!!!
Sagt mir bitte bitte bitte nicht, ich solle alle Leitungen auf der Platine noch einmal kontrollieren, ich hab das bestimmt 1000 mal gemacht. Ich habe eine noch unbestückte Platine genommen und alle Verbindungen durchgeklingelt ob ich im PCB auch keine Leitung vergessen habe (und das ganze zuvor natürlich auch im Layoutprogramm).
Ein Unterschied zum Steckbrett ist, dass ich auf dem PCB soviele GPIO Pins auf einen Header gelegt habe, sollte ich mit der Platine etwas anderes als EasyPdkProgrammer machen wollen.
Hier kann ich auch jeden einzelnen Pin auch ansprechen und Programme für den STM32F72 über DFU-Util flashen
ja, ich habe jedem Vcc-Pin einen 100nF Kondensator gegeben, auch dem bei Vbat (den ich bei Fehlersuche auch einmal abgelötet habe. Es könnte ja sein.
ich habe die Dämpfungswiderstände in der USB-Leitung variiert, von 10 Ohm bis 100 Ohm in der E12 Reihe.
So, jetzt kommt mein Kuriosum, das mich schier "umbringt":
Die Platine habe ich "Scheibchenweise" aufgebaut (und dabei einen eigentlichen Test "vergessen").
Zuerst also den STM32 aufgelötet mit sämtlichen 100nF Kondensatoren und der Beschaltung für Reset und Boot0 mit samt den Tastern. Quarz 8 MHz mit 22 pF Ziehkondensatoren, Header für ST-Link und USB-Buchse. Leuchtdiode an PC15.
Erster Test: Versuch Programmupload mit ST-Link. Erfolgreich, Blinken lassen an PC15 => LED blinkt
Zweiter Test: STM32 in Bootloadermodus versetzen und Blinkupload mittels DFU-Bootloader (ST-Link ist natürlich abgezogen). Erfolgreich, Blinken an PC15 funktioniert.
Aufbau Stepupwander, Messen der Spannung => Funktioniert.
Also den Rest bestückt (Fehler, ich hätte schon auch einmal die Firmware des Programmers aufspielen sollen, hier hätte ich gemerkt, dass er sich mit dem USB dann nicht anmeldet).
Das ist dann auch mein großes Problem, das mich schier umbringt.
Also, Firmware auf die Steckbrettversion aufgespielt (beide Chips sind STM32F072C8) und dieselbe Binärdatei auf dem Seckbrett meldet sich an:
1
Bus 002 Device 003: ID 05e3:0607 Genesys Logic, Inc. Logitech G110 Hub
2
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
3
Bus 008 Device 002: ID 413c:2106 Dell Computer Corp. Dell QuietKey Keyboard
4
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
5
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
6
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
7
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
8
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
9
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
10
Bus 003 Device 014: ID 0483:5740 STMicroelectronics STM32F407
11
Bus 003 Device 012: ID 046a:000c Cherry GmbH
12
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Hier irritiert mich STMicroelectronics STM32F407 nicht, das war schon immer so und ist in der Firmware (nicht von mir geschrieben) so verankert.
Gleiche Firmware auf meine PCB-Version aufgespielt: Schaltung meldet sich NICHT an.
Wie kann das sein? Die Verbindung zu USB (Hardware) muß doch funktionieren, sonst könnte ich den Chip doch nicht mittels USB DFU-Bootloader flashen.
Die Ausgabemeldung beim Flashen der Chips ist bei Steckbrett und PCB absolut identisch.
By the way: Flashe ich den Chip mittels ST-Link funktionierts auf dem Steckbrett (natürlich) und auf der Platine (natürlich) nicht!
Und dann meine (ganz eindeutige) Frage: was mache ich falsch und was kann ich noch kontrollieren (bevor ich eine zweite Platine bestücke)?
PS: und im Anhang an die Blockkondensator-Fanatiker ein Screenshot des PCB. Man kann die besser positionieren, aber glaubt ihr wirklich, dass das daran liegt (immerhin geht ja DFU-Bootloader mit USB).
ich habe die Dämpfungswiderstände in der USB-Leitung variiert, von 10
Ohm bis 100 Ohm in der E12 Reihe.
Zitat Datenblatt: No external termination series resistors are required on USB_DP (D+) and USB_DM (D-); the matching impedance is already included in the embedded driver.
Spannungsregler belastet man an seinem Ausgang grundsätzlich
nicht mit grossen Kapazitäten. 10uF wären eine gängige Grösse.
Ausnahmen bestätigen die Regel.
Grosse Kapazitäten am Ausgang verschlechtern die Regel-
eigenschaften eines Spannungsreglers. Ob das bei deinem
"Design" eine Rolle spielt wage ich von hier aus nicht zu
beurteilen.
Zitat Datenblatt: No external termination series resistors are required
on USB_DP (D+) and USB_DM (D-); the matching impedance is already
included in the embedded driver.
natürlich hatte ich die Widerstände auch schon draußen und mit 0-Ohm Brücken gesetzt. Das war es nicht!
Die Leiterplatte stimmt nicht mit dem Schaltplan überein. Der
1,5kΩ-Widerstand von PA13 zu VBUS fehlt in letzterem. Der muß raus.
Wenn du dir den Layoutscreenshot anschaust dann wirst du sehen, dass der 1,5k Widerstand erst über die Lötbrücke BR1 mit VBus verbunden wird. Ich hatte die Platine so gemacht, dass sie eben auch für andere Dinge evtl. genutzt werden kann.
Natürlich hatte ich den Widerstand zuerst draußen, aber in meiner "Not" hab ich alles ausprobiert (auch die Dinge, die eigentlich keinen Sinn machen.... :-) ich sollte sinnlose Dinge bleiben lassen).
Also, der 1,5k Widerstand ist es definitiv auch nicht !
Grosse Kapazitäten am Ausgang verschlechtern die Regel-
eigenschaften eines Spannungsreglers. Ob das bei deinem
"Design" eine Rolle spielt wage ich von hier aus nicht zu
beurteilen.
Weiß ich eigentlich auch (Regeflverhalten wird "langsam")... aaaaber (auch wenn ich das nicht glaube) werde ich den C am Ausgang wegnehmen (der ist eigentlich ein Angst-Kondensator des Stepup-Wandlers wegen).
Zeige den Verlauf deiner Masse im Layout. Auf dem Steckbrett
hast du ja nicht kapiert dass man Lastkapazitäten (nein, es
heisst nicht Ziehkondensatoren) mit ihrer Masse auf den
nächstgelegenen Massepin des Controllers legt und nicht auf
irgendeine Masse. Ja, Masse != Masse.
Der Kondensator am Spannungsreglerausgang war es natürlich (leider) auch nicht. Am Ausgang 100nF, dann 100nF // 1µF.... und 100nF // 4,7µF
Allerdings hatte ich nicht wirklich erwartet, dass der Fehler dort liegt.
Puuuh, ich weiß gar nicht, wie oft ich kontrolliert habe, ob das überhaupt der richtige Chip ist (hier habe ich unterschiedliche STM32 im LQFP48 - Gehäuse)
Aber (auch hier leider): es ist ein STM32F072C8.
Natürlich habe ich auch das originale Programm überprüft. Da wird zwar auch eine Datei eingebunden (Startupdatei) namens startup_stm32f072xb.S, aber in der Beschreibung dort ist zu lesen, dass diese Datei gleichermaßen für 072x8 und 072xb gilt. Der Unterschied der beiden liegt im maximalen Flashspeicher (64k zu 128k), Ram ist bei beiden 16k. Das Programm selbst bindet dann aber auch einen STM32F072C8TX_FLASH.ld ein, in dem die Angabe
Zeige den Verlauf deiner Masse im Layout. Auf dem Steckbrett
hast du ja nicht kapiert dass man Lastkapazitäten (nein, es
heisst nicht Ziehkondensatoren) mit ihrer Masse auf den
nächstgelegenen Massepin des Controllers legt und nicht auf
irgendeine Masse. Ja, Masse != Masse.
Wenn du dir das Bild des Steckbretts (welches im Übrigen problemlos läuft) genau anschaust, dann wirst du feststellen, dass die LASTKAPAZITÄTEN (ist es nicht egal wie die geschrieben werden, jeder weiß was damit gemeint ist) nicht auf die Masseschine des Bretts gehen, sondern quer zum PIN 8 (eben Masse).
Dass das auf dem Steckbrett nicht besser geht, ist schlicht dem geschuldet, dass es eben auf einem Steckbrett aufgebaut ist.
Auf dem Layout (komme ich gerade nicht ran) weiß ich, dass die Masseverbindung schon sehr knapp an Pin 8 geht.
Im Übrigen finde ich das Wort "kapiert" schon xyz (zensiert), "verstanden" wäre besser mal ganz davon abgesehen, dass ich das schon sehr wohl verstanden habe! Von daher vielen Dank für die "Belehrung".
Natürlich habe ich, so gut es geht dennoch versucht das umzusezten was du schreibst und einen Draht von den "Lastkapazitäten" direkt nach Pin 8 verlegt. Natürlich ohne Erfolg.
Dann habe ich ein kleines Programm geschrieben, dass über einen Timer ein Rechtecksignal 4096 Hz an PA3 erzeugen soll. Ergebnis mit einem alten Hameg Frequenzzähler HM8021-3 (was anderes habe ich halt nicht) sagt mir, dass die Frequenz um kleiner als 60 ppm (nach unten) abweicht.
Glaubst du wirklich, dass mein Problem an einer Masseleitung bei den Lastkapazitäten des Quarzes liegt (wenn doch ein DFU-Bootloading so problemlos funktioniert).
Meine nächsten Versuche (allerdings nicht heute) werden sein, einen Chip aus dieser Charge zu nehmen, ihn auf einer Adapterplatine löten und in die Schaltung auf dem Steckbrett einsetzen um zu sehen wie der dort reagiert.
Hier irritiert mich STMicroelectronics STM32F407 nicht, das war schon
immer so und ist in der Firmware (nicht von mir geschrieben) so
verankert.
Gleiche Firmware auf meine PCB-Version aufgespielt: Schaltung meldet
sich NICHT an.
Wie kann das sein? Die Verbindung zu USB (Hardware) muß doch
funktionieren, sonst könnte ich den Chip doch nicht mittels USB
DFU-Bootloader flashen.
Da gibt's schon einen Unterschied: Der Bootloader aktiviert CRS und gewinnt den Takt für USB via HSI48 und CRS (s. AN2606 13.1). Bei der Firmware ist das Sache der Firmware. Vielleicht über HSE und Quarz??? Wenn der Aufbau auf Steckbrett und Platine tatsächlich im Wesentlichen identisch ist, spielt event. die Leitungsführung etc. am Quarz eine Rolle. Schon eine geringe Abweichung von der Sollfrequenz, und USB klappt nicht mehr (zuverlässig).
Sowohl HSI48 als auch PLL-Takt (nur die beiden sind für USB möglich) kann man auf den MCO-Ausgang legen und messen - der Eingriff in die Firmware ist minimal (wenn man die Sourcen hat und der Pin nicht anderweitig fest belegt ist).
Das... wird dann eine heikle Sache, die Firmware liegt zwar im Source vor, aaaaber, zumindest für mich, etwas sehr undurchsichtig. Ich werde mal sehen ob ich nicht ein einfaches USB Programm selbst erstelle und schau was geht oder nicht. Mit dem 72er habe ich das noch nie gemacht.
@Guido: einfache Sache: weil es die Firmware schon fix und fertig gibt.
Das... wird dann eine heikle Sache, die Firmware liegt zwar im Source
vor, aaaaber, zumindest für mich, etwas sehr undurchsichtig. Ich werde
mal sehen ob ich nicht ein einfaches USB Programm selbst erstelle und
Dann weiß man aber immer noch nicht, was die Firmware macht ...
schau was geht oder nicht. Mit dem 72er habe ich das noch nie gemacht.
Testweise 8Mhz-Oszillator oder Funktionsgenerator statt Quarz anschließen ...
Um einen Hardwarefehler auszuschließen könntest du ein kleines Hello-World auf Basis der HAL oder dem hier im Forum veröffentlichten Code ausprobieren.
Schwingt der Oszillator? Die Masseleitung von den C's zum GND scheint mir recht lang zu sein, ggf. vertausche mal die Position des Quarzes und der beiden C's. Ich persönlich schwöre ja auf fertige Oszillatoren: klein und no trouble
Du hast die Vias sind in der Lötstop maske freigestellt. Eine Via ist am Quarzgehäuse. Setz den Quarz mal ein paar 10tel mm höher. Pads am Quarz sind auch sehr groß. Vermutlich produziert das Quarzgehäuse einfach einen Kurzschluss.
Ich habe bei mir deshalb bei HC49 Quarzen auf der Top Seite immer eine sehr kleine Freistellung in der Lötstopmaske. Das ist bei fest in den Libs drin.
Den STM32F072 betreibe ich typischerweise mit einem 12MHz Quarz in USB-Applikationen (oder eben quarzlos mit internem Oszillator und PLL Tuning). Die 12MHz begegnen mir auch immer wieder in öffentlichen Schaltplänen. Von daher finde ich die 8MHz zumindest ungewöhnlich (kann aber natürlich so funktionieren).
Gute Frage, zur Kontrolle könnte man clock out (MCO) benutzen. Und: Bei diesem STM32 Modell kann die USB Schnittstelle auch ohne Quarz funktionieren, wenn er entsprechend konfiguriert ist (mein vorhin verlinktes Beispiel tut das).
Du hast die Vias sind in der Lötstop maske freigestellt. Eine Via ist am
Quarzgehäuse. Setz den Quarz mal ein paar 10tel mm höher. Pads am Quarz
sind auch sehr groß. Vermutlich produziert das Quarzgehäuse einfach
einen Kurzschluss.
Das wäre das nächste was ich versucht hätte oder machen werde.
Sodele, mein Problem ist gelöst. Die Zusammenfassung meiner Versuche:
mit dem eingelöteten Chip läuft USB ohne ext. Quarz nicht (was mich stutzig gemacht hat)
Chip aus der Charge auf einen Adapter gelötet und in das Steckbrett gesteckt => läuft nicht (USB ohne ext. Quarz läuft hier auch nicht)
Chip aus anderer Charge und STM32F072B (nicht 8) auf Adapter gelötet und in das Steckbrett gesteckt => funktioniert
neue Platine bestückt (sogar mit nicht wirklich vorteilhaftem Sockel für den Quarz) und Chip STM32F072B => funktioniert sofort nach einschalten.
Versuch mit dem funktionierenden PCB (und gesockeltem Quarz):
DFU USB-Bootloader läuft beim STM32F072 auch ohne externen Quarz
Grundsätzlich stellt sich mir jetzt die Frage, ob es einen grundlegenden Unterschied zwischen -8 und -C Typ gibt (was ich mir nicht vorstellen kann, weil auf dem ursprünglichen Steckbrett ein -8 eingebaut ist), oder ist da dann evtl. doch ein Fake-Chip zugange (Lieferant war www.lcsc.com). Allerdings so recht glauben mag ich das nicht.
Wie dem auch sei: vielen Dank für die Hinweise, gelernt habe ich einiges.
im Gegensatz zu STM32F4 geht DFU auch ohne Quarz
ich werde (da ich immer mehr Chips, min. 5, bestelle) einen Chip erst ausserhalb einer Platine oder auf einer funktionierenden Platine testen.
Grundsätzlich stellt sich mir jetzt die Frage, ob es einen grundlegenden
Unterschied zwischen -8 und -C Typ gibt (was ich mir nicht vorstellen
kann, weil auf dem ursprünglichen Steckbrett ein -8 eingebaut ist)
Du könntest ja auch mal die vollständigen Device Typen angeben anstatt immer von -8. -C und -B zu reden. Die Device Vielfalt ist bei ST ja enorm. Dann könnte man in den DBs suchen.
Du könntest ja auch mal die vollständigen Device Typen angeben anstatt
immer von -8. -C und -B zu reden. Die Device Vielfalt ist bei ST ja
enorm. Dann könnte man in den DBs suchen.
vom "-C" habe ich nicht gesprochen. Es sind die Typen STM32F072C8 und STM32F072CB.
Beide besitzen ein gemeinsames Datenblatt (siehe auch Screenshot). Im Datenblatt wird hier explizit aufgeführt: STM32F072x8/xB !
Aber für mich hat es sich sowieso erledigt, weil ich eben einen STM32072C8 habe der funktioniert und einen, der nicht funktioniert (warum auch immer).
Mittlerweile habe ich 3 Platinen komplett bestückt (weil 2 meiner Bekannten des Programmer haben möchten) und alle 3 laufen einwandfrei !
Grundsätzlich stellt sich mir jetzt die Frage, ob es einen grundlegenden
Unterschied zwischen -8 und -C Typ gibt
Damit konnte ich auch nichts Anfangen, denn dein C8 ist beides, wenn man es locker sieht. Nur ist dann nicht klar, welches Modell denn der andere sein soll, der funktioniert.
vom "-C" habe ich nicht gesprochen. Es sind die Typen STM32F072C8 und
STM32F072CB.
natürlich hast du siehe Beitrag "Re: USB Problem bei STM32F072C8"
ich habe dich auch korrekt zitiert.
Wenn man ins ERATA schaut sind dort 3 Chip Revisionen mit unterschiedlichen Chip IDs aufgeführt.
Zumindest ein USB issue scheint in den beiden letzten Refs gefixt zu sein.
"The USB BCD electrical parameter not in line with specification"
Mich würde das an deiner Stelle schon interessieren warum ein Chip geht und der andere nicht.
Bei Quarzen gibt es viele Unterschiede, vielleicht mag der Controller die alten dicken Quarze nicht. Es gibt eine AppNote von ST dazu. Ich kenne die Probleme von den 32 kHz Quarzen, zum Strom sparen werden die mit geringem Strom betrieben und einige Controller haben dafür eine Einstellung.
Mich würde das an deiner Stelle schon interessieren warum ein Chip geht
und der andere nicht.
sagen wir es einmal so: Ich habe entnervt aufgegeben, und neue STM32F072C8 bestellt um zu sehen, ob das ein Ausrutscher war.
Außerdem bin ich auf der Suche, ob etwas bekannt darüber ist, ob der Chip (ähnlich dem STM32F103) gefaked wurde und wenn ja, ob es ein "Erkennungsprogramm" dafür gibt.
(boah, was "schwierig", wenn man die komplette Chipbezeichnung schreiben soll. Es war doch klar, dass es hier um einen STM32F072 geht ... und da sollte es doch eigentlich reichen wenn man schreibt: die C8 oder die CB Version... oder auch x8 oder xB Version ... wie das ST in seinen Datenblättern auch macht)
und da
sollte es doch eigentlich reichen wenn man schreibt: die C8 oder die CB
Version... oder auch x8 oder xB Version ... wie das ST in seinen
Datenblättern auch macht
Ja gerne, das hätte so gereicht.
Aber du hast Verwirrung gestiftet, indem nach den "generellen" Unterschieden zwischen Modell -8 und -C fragtest, während es zuvor um den STM32F072C8 ging.
Anders gesagt:
Ich habe hier einen kleinen roten Apfel. Wo ist nun der Unterschied zwischen klein und rot? Sind kleine Äpfel grundsätzlich anders als rote? (Falls ja: wie kann es dann sein, dass mein Apfel klein und rot ist?)
layout_stm32f072c8.png
(130 KB)
easy_pdk_programmer_steckbrett_kl.jpg
(240 KB)
padauk_pfs_programmer_2.jpg
(86 KB)
easypdk_foto_2.jpg
(470 KB)
