die Suche nach dem USB Problem mit diesem Board
https://github.com/mcauser/MCUDEV_DEVEBOX_H7XX_Mhttps://github.com/mcauser/MCUDEV_DEVEBOX_H7XX_M/blob/master/docs/STM32H7XX_M_schematics.pdf
wurde mir noch erschwert duch ein Problem dem 32k LSE clock. Dieser wird
für den LPTImer verwendet und weckt die CPU aus dem sleep mit WFI auf.
Zum Testen habe ich den HSE dann auf den MCO1 geschaltet und siehe da,
Frequenz = 0.
Ich habe noch zwei Boards von diesen und die auch getestet: das zweite
schwingt schon mehr, aber sehr schwankend mit ca. 25 +/- 5 kHz. Das
dritte hatte einen korrekten Takt von 32,76 kHz.
Sind diese 32 k Quarze generell so schlecht? Insgesamt machen diese
DevEBox Boards einen guten Eindruck, mit über 20 € ist das auch keine
Ramschware.
Bringt es was den mit Lötkolben oder Heissluft nachzubraten? Den Quarz
könnte ich vielleicht noch wechseln, aber die 10p C8/C9 sind eine Nummer
zu klein.
ich habe jetzt den Quarz getauscht, durch einen etwas grösseren, aber
gleicher Fehler: Frequenz springt bei ca. 25 kHz hin und her. Dann die
C8/C9 ausgelötet und mit SMD Tester nachgemessen: glatte 10 pF wie soll
im Schaltplan.
Dann im RefMan gefunden das man beim H7 den Treiber vom Oszillator in
vier Stufen einstellen kann, alle probiert, immer noch negativ.
So, die __HAL_RCC_LSEDRIVE_CONFIG darf man nur verstellen wenn LSE nicht
läuft. Nach einem Power off/on wirkt die Einstellung und die Uhr tickt
richtig.
Sheisse, ist der H7 kompliziert. Da wollte STM die beste ELWMS des
Universums bauen.
Und Mist,
wie kriege ich die Mikroskopisch kleinen C wieder eingelötet?
Johannes S. schrieb:> wie kriege ich die Mikroskopisch kleinen C wieder eingelötet?
Mit zwei Lötkolben mit kleinen spitzen Spitzen.
Zur Unterstützung kann man mit einer Heizplatte (oder Ofenplatte)
die gesamte Leiterplatte auf z.B. 80°C hochheizen, dann geht das
schon recht einfach.
Johannes S. schrieb:> So, die __HAL_RCC_LSEDRIVE_CONFIG darf man nur verstellen wenn LSE nicht> läuft.
Verrätst du uns noch auf welchen Wert du sie eingestellt hast
damit dein Zeugs funktioniert?
aber sicher doch:
Im RefMan RM0433 Rev 7, S. 424 ist die Beschreibung vom 'RCC Backup
Domain Control Register (RCC_BDCR)'.
Da gibts die Bits 'LSEDRV[1:0]: LSE oscillator driving capability',
default ist 00: Lowest drive. Mein Quarz lief mit der nächsthöheren
Einstellung '01: Medium low drive'.
Um zu sehen was die Treibereinstellung macht muss man wieder ins
Datasheet gucken, das sind 290 390 550 / 900 nA bei 00..11.
Und man muss tatsächlich warten bis der clock weg ist, das dauert ein
paar Sekunden bis der C von der Backup Power Domain leer ist. Oder
vielleicht den HSE explizit vorher stoppen, aber die Einstellung macht
man ja eigentlich nur einmal wenn man sie kennt.
über die HAL Makros ging das mit:
und in dem __HAL_RCC_LSEDRIVE_CONFIG ist noch eine Revisionsabhängigkeit
vom Chip mit drin, das will man nicht mehr alles selber über
Registerprogrammierung machen.
Löt Mann schrieb:> Mit zwei Lötkolben mit kleinen spitzen Spitzen.
ich hatte auch schonmal den Finger auf dem Button für eine zweite
einfache Lötstation für sowas, war dann aber doch zu geizig. Aber ich
glaube auch dafür darf ich zwei Tage lang keinen Kaffee getrunken haben
:)
Ich hatte auch schon Daten zu dem Quarz Y1 gesucht, da steht A805C
drauf, aber google konnte mir nicht helfen. Was für ein Teil könnte das
sein?
Johannes S. schrieb:> Was für ein Teil könnte das sein?
Naja, eben ein 32KHz-Quarz in entsprechend kleiner Bauform,
vermutlich das kleinste was zur Zeit erhältlich ist.
Oder was willst du sonst noch darüber wissen? Deine Frage
ist hiermit nicht klar genug gestellt.
welchen drive level der lt. Datenblatt braucht um das passend
einzustellen. Es läuft jetzt mit minimum, reicht das? Zuviel ist nicht
gut für die Lebensdauer habe ich gelesen, also macht es schon Sinn das
richtig einzustellen. Das ist aber auch der este µC den ich habe der das
so genau nimmt.
Die Abmessungen sind 3,2 x 1,5 x 0,8 mm. Aber für heute habe ich genug
Detektiv gespielt.
doch noch bei Mouser geguckt, findet 53 mit diesen Abmessungen. Ich
suche später weiter.
Danke für die Tipps.
Johannes S. schrieb:> welchen drive level der lt. Datenblatt braucht um das passend> einzustellen. Es läuft jetzt mit minimum, reicht das?
Der Einstellbereich umfasst einen Bereich 1 bis 3-fach, das
ist jetzt nicht soviel dass man da was kaputt machen könnte.
Ist wohl eher dazu gedacht den Oszillator sicher anschwingen
zu lassen. Ich nehme an dass die interne Beschaltung dafür
sorgt dass nicht zuviel Aussteuerung auf den Quarz kommt.
Mit ner 0,2mm Lötspitze und der passenden Pinzette sollte das doch noch
gehen?
Jedenfalls danke für die Detektivarbeit.
Johannes S. schrieb:> Sheisse, ist der H7 kompliziert.
Warts ab bis du was mit den Caches zu tun hast ;)
Aber da kann ich dir dann helfen, mit dem LSE hab ich einfach noch nie
was zu tun gehabt.
Habe mich gerade mal hier durchgewühlt:
https://www.st.com/resource/en/application_note/cd00221665-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf
Ich behaupte mal der LSE Quarz ist das komplizierteste Teil bei dem
Board Design, alleine die Liste der recommended parts für LSE ist 13
Seiten lang.
Und mit 3,2 x 1,5 mm gehört der auf meinem Board schon zu den dicken
Brummern... Der Default für den DL beim H7 ist jedenfalls definitiv zu
niedrig für einen Quarz mit 10 pF Last C, die Einstellung mid-high
sollte auch ok sein.
Die Caches scheinen im Mbed Code berücksichtigt zu sein, da habe ich
einige DSB/ISB in den ISR gesehen. Auch locks und Fallunterscheidungen
für Dualcores, weil es geht ja noch komplizierter.
Und in og Dokument sind die ST Familien aufgelistet, die Einstellungen
für LSE sind sehr unterschiedlich.
Danke, das sind auch tückische Fehler weil die Ursache ja nicht so
offensichtlich ist.
ST scheint die H7 Serie trotzdem als Mädchen für alles zu sehen, wenn
die schon beim STLink einen F103 durch einen H7 ersetzen.
Johannes S. schrieb:> Da gibts die Bits 'LSEDRV[1:0]: LSE oscillator driving capability',> default ist 00: Lowest drive. Mein Quarz lief mit der nächsthöheren> Einstellung '01: Medium low drive'.
Da gibt's aber noch die nette Falle im Errata Sheet "2.2.14 LSE
oscillator driving capability selection bits are swapped" bei Rev. Y
gegenüber Rev. V zu beachten ...
Johannes S. schrieb:> ST scheint die H7 Serie trotzdem als Mädchen für alles zu sehen, wenn> die schon beim STLink einen F103 durch einen H7 ersetzen.
Nein, das ist ein F723, kein H7. Der F723 ist wohl der einzige STM32 mit
internem USB-HS-PHY. Irgendwie seltsam, bei NXP ist das eher normal, bei
ST ein absoluter Exot.
A. B. schrieb:> Da gibt's aber noch die nette Falle im Errata Sheet
Ja, schrieb ich ja das im HAL Makro die Revisionsabhängigkeit
berücksichtigt wird:
https://github.com/STMicroelectronics/STM32CubeH7/blob/beced99ac090fece04d1e0eb6648b8075e156c6c/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_rcc.h#L7727-L7757
Aber da ist die Frage wo das Define RCC_VER_X herkommt, das muss ich
wohl noch selber setzen.
Edit:
das RCC_VER_X wird im CMSIS header stm32h743xx.h für das device gesetzt.
Die github Suche findet nicht alles, auch blöd.
A. B. schrieb:> Nein, das ist ein F723, kein H7.
Auch richtig, werfe gerne die F und H durcheinander. Und über den
fehlenden HS Phy schimpfen auch viele. Vor allem weil die ULPI
Anschlüsse schön verteilt sind, prima bei 8 Daten Leitungen @ 60 MHz.
