Hatte mir durch eine Fehlpolung (0-5V) mein STM32F407-DISC1 Board geschlachtet. Da sich danach die MCU noch programmieren ließ (STM32-STLINK-Utility), das Programm selbst aber nicht lief (eine UART-Ausgabe wäre das einzige Lebenszeichen gewesen, aber die kam nicht), habe ich auf den STM32F407VGT6 getippt und diesen ausgewechselt. Effekt ist aber nach wie vor derselbe. Neuer Chip läßt sich auch programmieren, aber Programm selbst scheint nicht zu laufen. Der SWDIO-Teil ist weitgehend abgeklemmt (ich programmiere den Chip mit der ST-LINK SWD-Sektion eines Nucleo-Boards). Ich will die Hoffnung noch nicht aufgeben, das Board irgendwie wieder zum Laufen zu bekommen. Hat jemand vielleicht noch ein paar Ideen? Spannungen (3V, 5V) sind jeweils alle da. Werde jetzt mal den STM32F103 aus der ST-LINK Sektion auslöten.
Christoph K. schrieb: > Hat jemand vielleicht noch ein paar Ideen? Nur eine. Du steckst da Stunden, Tage, Wochen an Arbeit rein (hab schon einiges darüber gelesen ....). Hirnrissig sich da hineinzusteigern. Dabei könntest du für geschätzte 20 Euro ein neues Board kaufen. Discovery-compatible Boards (ohne den ganzen Klimbim den man nicht braucht) bekommt man bei ebay für 15-20 Euro.
Ich habe ja auch hier schon nach einem gebrauchten gleichen Board gesucht. Weil das Board in einen vorhandenen Aufbau gesteckt wird, muß es genau dieser Typ sein. Auch sind an dem Board schon einige Modifikationen gemacht, so daß ich es lieber erhalten würde.
Christoph K. schrieb: > aber Programm selbst scheint nicht zu laufen. Das lässt sich ja mit dem ST-Link prüfen. Und wann er aussteigt. Schuß ins Blaue: Taktsignal da?
Christoph K. schrieb: > Auch sind an dem Board schon einige Modifikationen > gemacht, so daß ich es lieber erhalten würde. Wie sollen wir dir denn gute Ratschläge geben, was kaputt sein könnte, ohne die Modifikationen zu kennen?
Christoph K. schrieb: > eine > UART-Ausgabe wäre das einzige Lebenszeichen gewesen, aber die kam > nicht Hat das Board keine LEDs sonst versuch doch darüber mal Lebenszeichen zu bekommen? Ich glaube auch nicht, dass es den Aufwand wert ist. Christoph K. schrieb: > ich programmiere den Chip mit > der ST-LINK SWD-Sektion eines Nucleo-Boards Warum nicht über den eigenen ST-Link? Wenn du das Board unbedingt retten möchtest kannst du dir ja auch mal den Schaltplan angucken und überlegen wo die falsche Spannung schaden könnte. Da du ja einiges modifiziert hattest und nicht allzuviel Informationen genannt hast ist es aus der Ferne schwer abzuschätzen was es zerbraten hat ;)
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Auch sind an dem Board schon einige Modifikationen >> gemacht, so daß ich es lieber erhalten würde. > > Wie sollen wir dir denn gute Ratschläge geben, was kaputt sein könnte, > ohne die Modifikationen zu kennen? Es sind ein Haufen Lötbrücken, und trace cuts im Bereich des OTG . Das würde jetzt auch nichts beitragen. Hatte es in einem anderen Thread mal alles aufgeführt. Man muß sich vorstellen, daß das Discovery so verändert wurde, daß alle Pins der extenen Schaltung zur Verfügung stehen. Die Verpolung ist mir passiert, als das Board in der Luft war, also nur mit Power- und Programmierleitungen am Nucleo hing.
Walter T. schrieb: > Christoph K. schrieb: >> aber Programm selbst scheint nicht zu laufen. > > Das lässt sich ja mit dem ST-Link prüfen. Und wann er aussteigt. Schuß > ins Blaue: Taktsignal da? PH0/PH1 8MHz?
Verstehichnich schrieb: ... > Discovery-compatible Boards (ohne den ganzen Klimbim den man > nicht braucht) bekommt man bei ebay für 15-20 Euro. Wahrscheinlich muß ich dann 4 Wochen drauf warten (China). Und letztlich weiß man nicht genau, was man bekommt (gefälschter Chip mit Mängeln). Alternative wäre, jetzt ein neues Board zu kaufen. 35 Eur ist im Moment das Günstigste, was ich finden konnte.
:
Bearbeitet durch User
Christoph K. schrieb: > Man muß sich vorstellen, daß das Discovery so > verändert wurde, daß alle Pins der extenen Schaltung zur Verfügung > stehen. Wenn das so ist, dann ist da also kein Bauteil mehr übrig, dass für die Funktion relevant ist. Dann hätte der Austausch des Mikrocontroller klappen müssen. Irgend etwas ist anders. Ich würde dringend empfehlen, das in Form eines Schaltplanes zu dokumentieren.
Christoph K. schrieb: > Hat jemand vielleicht noch ein paar Ideen? Spannungen (3V, 5V) sind > jeweils alle da. Werde jetzt mal den STM32F103 aus der ST-LINK Sektion > auslöten. Wenn Du Dir damit nicht noch mehr Fehler reinholst ... der STM32F103 hängt mit ein paar Pins am STM32F407, die man leichter auftrennen kann als den 103er auszulöten. https://circuit-diagramz.com/wp-content/uploads/2016/12/schematics_SWD_only-1.jpg SWDIO und SWDCLK sind sowieso gejumpert und müssen nicht getrennt werden. Probier doch stattdessen, den STM32103 in seiner ursprünglichen Funktion als STLink zu enutzen, um einen anderen STM zu flashen. Wenn er das kann, ist er wahrscheinlich nicht kaputt.
Christoph K. schrieb: > Wahrscheinlich muß ich dann 4 Wochen drauf warten (China). Ja klar, immer gleich in China bestellen. Anders geht ja gar nicht, gell? Oh Mann, was es für Ausreden gibt ..... https://www.ebay.de/itm/STM32F407VET6-STM32-Cortex-M4-Development-Board-Mainboard-Module-NEU/233535468848 https://www.ebay.de/itm/STM32F407VGT6-STM32F4-ARM-Cortex-M4-32bit-MCU-Core-Development-Board/402328288186 Lieferung Dienstag 2. März: https://www.amazon.de/DollaTek-STM32F407VET6-Entwicklungsboard-Lernboard-Embedded-Entwicklungsboard/dp/B07PQPCV5S/ref=sr_1_25?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3QDS7W19741HZ&dchild=1&keywords=stm32f407+discovery+board&qid=1614362048&quartzVehicle=1820-1194&replacementKeywords=stm32f407+board&sprefix=stm32f407%2Caps%2C188&sr=8-25
Christoph K. schrieb: > Und letztlich > weiß man nicht genau, was man bekommt (gefälschter Chip mit Mängeln). Käse. Hab schon viele solche Boards bestellt, waren alle in Ordnung. F407 Chips sind bisher nicht als Fakes bekannt. mimimimimi .....
Wenn sich jemand so im Kreis dreht dann muss man sich echd uffregge über soviel Kleinkariert.
Christoph K. schrieb: > Alternative wäre, jetzt ein neues Board zu kaufen. 35 Eur ist im Moment > das Günstigste, was ich finden konnte. Für zwei? ;-) https://www.digikey.de/product-detail/de/stmicroelectronics/STM32F407G-DISC1/497-16287-ND/5824404
Für 1, Versand kostenlos. Bei Digikey kommen noch 18,00€ Versand hinzu. Allen, die mir hier irgendwas anderes als STM32F407-DISC1 empfohlen haben, sollten vorher besser lesen. Ich habe immer gesagt, ich brauche genau dieses Board. Danke an Rolf.M (rmagnus) für den Digikey-Tip. Immerhin interessant.
Christoph K. schrieb: > Ich habe immer gesagt, ich brauche > genau dieses Board. Brauchst du nicht, hast du indirekt auch schon zugegeben indem du ein anderes Board in Betracht gezogen hast. So lange wie du an der Reparatur deines Boards herumgepfuscht hast hättest du längst ein neues anderes Board in deinem Aufbau verdrahtet und wärst wieder am Laufen.
Christoph K. schrieb: > Danke an Rolf.M (rmagnus) für den Digikey-Tip. Immerhin interessant. Gibt's auch z.B. bei RS oder Reichelt. Bei letzterem wird's aber mit Versand schon auf die 35 € rauslaufen.
Rolf M. schrieb: > Christoph K. schrieb: >> Danke an Rolf.M (rmagnus) für den Digikey-Tip. Immerhin interessant. > > Gibt's auch z.B. bei RS oder Reichelt. Bei letzterem wird's aber mit > Versand schon auf die 35 € rauslaufen. Toll, das hatte der TE schon selber festgestellt: Christoph K. schrieb: > Alternative wäre, jetzt ein neues Board zu kaufen. 35 Eur ist im Moment > das Günstigste, was ich finden konnte. Warum lesen viele Foristen den Thread nicht durch, bevor sie eine Antwort geben? @ Christoph K., es wirkt etwas befremdlich, wenn Du an einem ganz bestimmten Board suchts, das sogar gebraucht, an dem Du selber "rumlötest", also z.B. die Schaltung veränderst, aber meckerst, wenn es nicht genau DAS Board ist, was jemand ggf. anführt. Oder die Lieferzeit aus China bemängels, aber versuchst, den Gebrauchtwarenmarkt abzugrasen, wo gerade Du dort auch keine Garantie hast, dass da noch alles läuft?
Christoph K. schrieb: > Effekt ist aber nach wie vor derselbe. Neuer Chip läßt sich auch > programmieren, aber Programm selbst scheint nicht zu laufen. Hat zwar nichts mit der 5V-Verpolung zu tun, aber dieses Fehlerbild könnte beim Umschalten von HSI auf HSE erscheinen, wenn der Quarz nicht läuft. Programmier doch mal einen Blinky mit HSI.
Ralf X. schrieb: > Rolf M. schrieb: >> Christoph K. schrieb: >>> Danke an Rolf.M (rmagnus) für den Digikey-Tip. Immerhin interessant. >> >> Gibt's auch z.B. bei RS oder Reichelt. Bei letzterem wird's aber mit >> Versand schon auf die 35 € rauslaufen. > > Toll, das hatte der TE schon selber festgestellt: > > Christoph K. schrieb: >> Alternative wäre, jetzt ein neues Board zu kaufen. 35 Eur ist im Moment >> das Günstigste, was ich finden konnte. Rate mal, worauf ich mich mit "die 35 €" bezogen habe! > Warum lesen viele Foristen den Thread nicht durch, bevor sie eine > Antwort geben? Warum kritisieren so viele Foristen Antworten, die sie gar nicht richtig erfasst haben?
Jürgen S. schrieb: > Christoph K. schrieb: >> Effekt ist aber nach wie vor derselbe. Neuer Chip läßt sich auch >> programmieren, aber Programm selbst scheint nicht zu laufen. > Hat zwar nichts mit der 5V-Verpolung zu tun, aber dieses Fehlerbild > könnte beim Umschalten von HSI auf HSE erscheinen, wenn der Quarz nicht > läuft. > Programmier doch mal einen Blinky mit HSI. Muß ich bei funktionierendem 8.000 MHz Quarz an PH0 am Chip eine Clock sehen? Bei meinem funktionierenden Anwendungsboard (das mit der Anwendungsfirmware geladen ist) sehe ich da keine Oszillation. Bei meinem "reparierten" Board auch nicht. Bei einem fabrikneuen mit Standard- Jumpersettings und der Standard-App sehe ich an R25(=PH0) die 8MHz. Ich weiß aber nicht, was man sehen muß, wenn die MCU auf 168MHz eingestellt ist.
Christoph K. schrieb: > Muß ich bei funktionierendem 8.000 MHz Quarz an PH0 am Chip eine Clock > sehen? Wenn du den Quarz Oszillator durch dein Messgerät belastest, könnte er dadurch anhalten. Bei AVR konnte ich mit meinem Oszilloskop den Takt sichtbar machen, aber nur an XTAL2 (das würde PH1 entsprechen) und nur wenn der Tastkopf auf 1/10 eingestellt ist. Ansonsten belastet wer den Oszillator zu stark. Für solche Kontrollen gibt es den MCO Pin, den man per Software aktivieren kann. Schau dir das Clock-Tree Diagramm im Refence Manual an, dann siehst du, welche Taktsignale man auf den MCO Ausgang legen kann. > Ich weiß aber nicht, was man sehen muß, wenn die MCU auf > 168MHz eingestellt ist. Die Frequenz des Quarz, ganz sicher keine 168 MHz.
Stefan ⛄ F. schrieb: > Wenn du den Quarz Oszillator durch dein Messgerät belastest, könnte er > dadurch anhalten. Das macht er erfahrungsgemäß nicht. > Bei AVR konnte ich mit meinem Oszilloskop den Takt sichtbar machen, Kann man ihn auch riechen? AVR != STM32 Christoph K. schrieb: > Bei einem fabrikneuen mit > Standard- Jumpersettings und der Standard-App sehe ich an R25(=PH0) die > 8MHz. Das ist das MCO-Signal vom F103.
m.n. schrieb: > Das ist das MCO-Signal vom F103. Wer weiß, welche Lötbrücken aufgetrennt wurden... Aus dem Usermanual: If PH0 and PH1 are used as GPIOs instead of being used as a clock, then SB13 and SB14 are closed and R24, R25 and R68 are removed. •MCO from ST-LINK. From MCO of the STM32F103. This frequency cannot be changed, it is fixed at 8 MHz and connected to PH0-OSC_IN of the STM32F407VG. Configuration needed:–SB13, SB14 OPEN–R25(a) removed–R68(a) soldered •Oscillator on board. From X2 crystal. For typical frequencies and its capacitors and resistors, refer to the STM32F407VG datasheet at www.st.com. Configuration needed:–SB13, SB14 OPEN–R25(a) soldered–R68(a) removed •Oscillator from external PH0. From external oscillator through pin 7 of the P2 connector. Configuration needed:–SB13 closed–SB14 closed–R25 and R68 removed Für den Blinky (mit HSE) gibt es hier ein Beispiel https://www.mikrocontroller.net/articles/STM32F4-Discovery Wenn das nicht geht, HSI probieren. Und bevor kein Blinky getestet wurde, sage ich hier garnix mehr.
Jürgen S. schrieb: > m.n. schrieb: >> Das ist das MCO-Signal vom F103. > Wer weiß, welche Lötbrücken aufgetrennt wurden... Christoph K. schrieb: > Bei einem fabrikneuen mit > Standard- Jumpersettings und der Standard-App sehe ich an R25(=PH0) die > 8MHz. Alles klar?
Christoph K. schrieb: > Muß ich bei funktionierendem 8.000 MHz Quarz an PH0 am Chip eine Clock > sehen? Christoph K. schrieb: > Bei meinem funktionierenden Anwendungsboard (das mit der > Anwendungsfirmware geladen ist) sehe ich da keine Oszillation. Dann wäre es jetzt wohl interessant, ob beim "funktionierenden" Board die MCU auch mit der richtigen Taktfrequenz läuft. Deine Taktquelleneinstellung kennst immer noch nur Du (hoffentlich). Sie erfolgt üblicherweise in SystemInit().
m.n. schrieb: > Alles klar? Hä? Wenn interessiert, was auf dem fabrikneuen Board passiert? > Christoph K. schrieb: > Bei meinem funktionierenden Anwendungsboard (das mit der > Anwendungsfirmware geladen ist) sehe ich da keine Oszillation. Bei > meinem "reparierten" Board auch nicht. Ich glaube, das Copy & Pasten sowie Testen eines Blinkys löst Kastrationsängste aus.
Jürgen S. schrieb: > Hä? Wenn interessiert, was auf dem fabrikneuen Board passiert? Der TO hatte danach gefragt und ich denke, zumindest er hat meine Antwort auch verstanden. Um Dich geht es hier nicht.
Jürgen S. schrieb: ... > > Für den Blinky (mit HSE) gibt es hier ein Beispiel > https://www.mikrocontroller.net/articles/STM32F4-Discovery > Wenn das nicht geht, HSI probieren. > > Und bevor kein Blinky getestet wurde, sage ich hier garnix mehr. Ich versuche gerade, das besagte Blinky-Beispiel zum Laufen zu bekommen. Leider funktioniert das Beispiel https://www.mikrocontroller.net/articles/STM32F4-Discovery nicht auf Anhieb. Man sehe es mir nach, daß ich noch keine funktionierende C/C++-Entwicklungsumgebung parat habe. (meine heißt 'vi' und 'make' und meine Anwendung ist in Assembler geschrieben. Ich will jetzt nicht wiederholen, warum es Assembler sein muß, aber daran ist nicht zu rütteln) Der Versuch, das unter dem Link befindliche main.c zu kompilieren, scheitert an einer fehlenden Datei stm32f4xx_gpio.h, nachdem ich das in main.c befindliche falsche #include "stm32f4xx.h" in #include "stm32f4xx_conf.h" abgeändert hatte. Vielleicht habe ich auch etwas übesehen/überlesen? Blinky Erfolgsmeldung kommt hoffentlich jetzt schnell.
:
Bearbeitet durch User
Christoph K. schrieb: > Blinky Erfolgsmeldung kommt hoffentlich jetzt schnell. Vielleicht geht's mit dem Code im Anhang noch etwas schneller.
jo mei schrieb: > Christoph K. schrieb: >> Blinky Erfolgsmeldung kommt hoffentlich jetzt schnell. > > Vielleicht geht's mit dem Code im Anhang noch etwas schneller. Danke. Habe zunächst das fabrikneue Board mit Deinem HEX-File geflasht. Es blinkt nichts. Danach wieder die Standard-App zurückgeflasht und Leds blinken in der gewohnten Manier.
Christoph K. schrieb: > Es blinkt nichts. Stimmt. Da muss ich nochmal "nachhaken". Christoph K. schrieb: > Danach wieder die Standard-App zurückgeflasht und Leds > blinken in der gewohnten Manier. Warum benutzt du nicht diese zum Testen deines zweiten Boards?
jo mei schrieb: > Christoph K. schrieb: >> Es blinkt nichts. > > Stimmt. Da muss ich nochmal "nachhaken". > > Christoph K. schrieb: >> Danach wieder die Standard-App zurückgeflasht und Leds >> blinken in der gewohnten Manier. > > Warum benutzt du nicht diese zum Testen deines zweiten Boards? Erst mal die App selbst testen an einem funktionierenden Board. Noch einmal zur Übersicht: Board A: nagelneues Board (MB997-D01, blauer Lötstopp) Board B: mein repariertes Board, wo Blinky-App.HEX aber nicht funktioniert Board C: "heiliges" Board mit der funktionierenden Anwendung B und C haben die Widerstände R36,R40,R41,R42 entlötet, weshalb ich nur mit dem Scope "gucken" kann, ob's blinkt. Board "B" und "C" funktionieren auch nicht mit Deiner Blinky-App.HEX Board "C" funktioniert auch nicht mit der Standard-App. B u. C sind ja speziell gejumpert.
:
Bearbeitet durch User
jo mei schrieb: > Stimmt. Da muss ich nochmal "nachhaken". Hier nochmal ein Testcode, der sollte aber funktionieren. Auf die Schnelle unerklärliche Ursache: Im Debugger lief der Code, wenn man ihn direkt ohne Debugger flashte dann nicht.
jo mei schrieb: > jo mei schrieb: >> Stimmt. Da muss ich nochmal "nachhaken". > > Hier nochmal ein Testcode, der sollte aber funktionieren. > > Auf die Schnelle unerklärliche Ursache: Im Debugger lief der > Code, wenn man ihn direkt ohne Debugger flashte dann nicht. Erst mal im Board A (blaues, gutes): Blinkt - 'n bißchen anders als die Standard app - gn/or 4 mal. Im "guten" Board C aber kein Blinken. Hier die Jumperung meines STM32F407G-DISC1: (||= offen, X = ausgelötet/entfernt, gold=unberührt, offen) SB2 || gold SB3 || SB4 || gold SB5 || SB6 || gold SB7 || SB8 || gold SB10 || SB11 || SB12 || SB13 || gold SB14 || gold SB15 || SB16 || SB17 || gold SB18 || SB19 || SB20 || R22 X R21 X R42 X R48 X R46 X R48 X R49 X R50 X R68 X (trennt MCO vom STM32F103 ab) U6 X LD1 X C61 N/A gold C49 X Nachtrag: Hier ist der verwendete Clock-Initialisierungscode, den mein Vorgänger benutzt hat. Er benutzt den PLL-Clockgenerator. Was für eine Funktion hat in dem Falle überhaupt noch der Quarz? Dient er zum Einlocken der PLL? ;--------------------------------------------------------------- ; Clocks ;--------------------------------------------------------------- .set HSECLK, 8000000 ; HSE crystal oscillator frequency .set SYSCLK, 168000000 ; main PLL output frequency .set RCLK, 48000000 ; RNG/USB clock frequency ;--------------------------------------------------------------- ; PLL configuration ; ; The critical PLL parameters are checked for validity. ;--------------------------------------------------------------- ; PLL input divider PLLM (allowed range: 2 - 63) ; PLLM must be chosen so that the PLL input frequency falls in the allowed ; range 1 - 2 MHz .set PLLM, 8 .if PLLM < 2 || PLLM > 63 .error "PLLM out of range" .endif ; PLL input frequency (allowed range: 1 - 2 MHz) .set f_PLLin, HSECLK / PLLM .if f_PLLin < 1000000 || f_PLLin > 2000000 .error "f_PLLin out of range" .endif ; PLL output divider DIVP (allowed values: 2, 4, 6, or 8) ; DIVP must be chosen so that f_VCO falls in the range 192 - 432 MHz .set DIVP, 2 .if DIVP != 2 && DIVP != 4 && DIVP != 6 && DIVP != 8 .error "DIVP out of range" .endif ; VCO frequency (allowed range: 192 - 432 MHz) .set f_VCO, SYSCLK * DIVP .if f_VCO < 192000000 || f_VCO > 432000000 .error "f_VCO out of range" .endif ; PLL multiplier PLLN (allowed range: 192 - 432) .set PLLN, f_VCO / f_PLLin .if PLLN < 192 || PLLN > 432 .error "PLLN out of range" .endif ; PLL divider PLLQ for RNG clock (allowed range: 2 - 15) .set PLLQ, f_VCO / RCLK .if PLLQ < 2 || PLLQ > 15 .error "PLLQ out of range" .endif .set PLLP, (DIVP - 2) / 2 ; PLLP is a 2-bit encoding for DIVP .set PLLSRC, 1 ; PLL clock source (0 = HSI, 1 = HSE) ; PLL configuration word to be loaded into RCC_PLLCFGR register .set PLLCONF, PLLQ << 24 | PLLSRC << 22 | PLLP << 16 | PLLN << 6 | PLLM ;-------------------------------------------------------------- ; Clock configuration for AHB, APB1 and APB2 peripherals ;-------------------------------------------------------------- .set HPRE, 0 ; AHB clock prescaler = 1 .set HCLK, SYSCLK ; AHB clock .set PPRE1, 5 ; APB low-speed clock prescaler = 4 .set PCLK1, HCLK / 4 ; APB low-speed clock .set PPRE2, 4 ; APB high-speed clock prescaler = 2 .set PCLK2, HCLK / 2 ; APB high-speed clock .set SW, 2 ; clock source (0 = HSI, 1 = HSE, 2 = PLL) ;.set LSE_fitted, 0 ; set to 1 if 32-KHz crystal fitted ;.if LSE_fitted ;.set LSEON, 1 ; enable LSE oscillator ;.set RTCSEL, 1 ; select LSE as RTC clock source ;.set RTCPRE, 0 ; RTC clock prescaler off ;.else ;.set LSEON, 0 ; disable LSE oscillator ;.set RTCSEL, 3 ; select HSE as RTC clock source ;.set RTCPRE, HSECLK / 1000000 ; RTC clock must be 1 MHz ;.endif ;.set RTCEN, 1 ; enable RTC clock ; clock configuration word to be loaded into RCC_CFGR register .set CLKCONF, PPRE2 << 13 | PPRE1 << 10 | HPRE << 4 | SW ;; clock configuration word to be loaded into RCC_BDCR register ;.set RTCCONF, RTCEN << 15 | RTCSEL << 8 | LSEON
:
Bearbeitet durch User
Beitrag #6608058 wurde vom Autor gelöscht.
In dem Bild siehst Du den Clock Konfigurator https://i.stack.imgur.com/gfzsT.png Du siehst auf der linken Seite 'HSI RC' (16 MHz), das ist der interne Taktgeber. Und 'HSE', das ist der externe 8MHz-Quarz mit einer drangehängten Oszillatorschaltung. Sowohl HSI als auch HSE können direkt als Systemtakt gewählt werden (am 'System Clock Mux', oder über die PLL laufen. Wenn über PLL, muß 'System Clock Mux' auf PLLCLK eingestellt sein, und mit dem 'PLL Source Mux' entscheidet man, ob man die PLL mit dem HSI oder dem HSE füttert. Die PLL multipliziert einfach Deine Eingangsfrequenz (HSI oder HSE), so daß Du eine ganze Bandbreite an Systemfrequenzen wählen kannst. Insofern brauchst Du den Quarz nicht, wenn Du HSI wählst, kannst aber trotzdem die PLL verwenden. In Deinem Sourcecode steht a) .set PLLSRC, 1 ; PLL clock source (0 = HSI, 1 = HSE) b) .set SW, 2 ; clock source (0 = HSI, 1 = HSE, 2 = PLL) c) .set PLLM, 8 Die 3 Einstellungen brauchst Du. a) bezieht sich dabei auf den 'PLL Source Mux' b) auf den 'System Clock Mux' c) auf den Eingangstakt (Quarzfrequenz HSE 8MHz bzw. Oszillator HSI 16MHz) PLLM ist auf 8 eingestellt, weil das Discovery einen 8MHz Quarz hat. Du mußt nur 2 Parameter verändern, wenn Du auf HSI umschalten willst und über die PLL gehst: a) .set PLLSRC, 0 ; PLL clock source (0 = HSI, 1 = HSE) c) .set PLLM, 16 Mit c) teilst Du eingangsseitig nicht mehr durch 8 wie bei HSE, sondern durch 16 wie bei HSI. Und mit a) wählst Du HSI aus. b) wird nicht geändert, weil der Pfad für HSI und HSE der gleiche ist. Wenn Du das so machst, müßtest Du ungefähr die gleiche Blinkfrequenz sehen, ob HSE oder HSI. Wenn Du mit HSI die doppelte Blinkfrequenz sehen möchtest, kannst Du c) auf ".set PLLM, 8" stehenlassen. Ich wußte nicht, daß Du keine Entwicklungsumgebung hast bzw. dbzgl. unerfahren bist. Und hoffe, Du kannst Deine eigene Codevorlage mit den vorhandenen Mitteln und mit den Parameteränderungen compilieren. Wenn nicht, vielleicht erbarmt sich 'jo mei' auch dazu, einen Code für HSI zu schreiben :) Edit: Ab ;.set LSE_fitted, 0 ; set to 1 if 32-KHz crystal fitted bezieht sich Dein Quelltext auf einen anderen Quarz, den 32.768kHz-Quarz für die Echtzeituhr. Der Teil spielt für den Blinky keine Rolle.
Danke, Jürgen, für die Erläuterungen. Das Clock-Blockschaltbild war mir bekannt - es vollständig zu verstehen oder es zu benutzen (CubeMX) ist etwas Lernkurve. Zwei Fragen hätte ich: Wird der externe, an PH0/PH1 angeschlossene, 8.000 MHz im HSI Falle überhaupt gebraucht? Was sorgt für die Präzision der intern erzeugten 168MHz (PLL)? Ich dachte immer, die interne Clock sei (wegen RC) ungenau. Grüße Christoph
Christoph K. schrieb: > Wird der externe, an PH0/PH1 angeschlossene, 8.000 MHz im HSI Falle > überhaupt gebraucht? Nein. > Was sorgt für die Präzision der intern erzeugten 168MHz (PLL)? Nichts. Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter geben. Mit HSI dürfte die Absolutfrequenz zudem nicht sehr genau 16MHz sein, damit auch die PLL-Frequenz nicht genau 168MHz sein. Mit HSI habe ich nie gearbeitet, weil bei mir auch immer ein UART in Aktion ist, und zur Sicherheit möchte ich dessen Baudrate quarzgenau einstellen können.
Jürgen S. schrieb: > Christoph K. schrieb: >> Wird der externe, an PH0/PH1 angeschlossene, 8.000 MHz im HSI Falle >> überhaupt gebraucht? > Nein. >> Was sorgt für die Präzision der intern erzeugten 168MHz (PLL)? > Nichts. Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter > geben. > Mit HSI dürfte die Absolutfrequenz zudem nicht sehr genau 16MHz sein, > damit auch die PLL-Frequenz nicht genau 168MHz sein. > > Mit HSI habe ich nie gearbeitet, weil bei mir auch immer ein UART in > Aktion ist, und zur Sicherheit möchte ich dessen Baudrate quarzgenau > einstellen können. Das wundert mich sehr. Wie kriegt man denn dann physikalisch exakte Aussagen/Anwendungen hin, wenn die Zeitbasis nicht zuverlässig ist? Oder kann ich die interne PLL mit dem externen Quarz locken?
Jürgen S. schrieb: >> Was sorgt für die Präzision der intern erzeugten 168MHz (PLL)? > Nichts. Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter > geben. Wie bitte? Um die PLL-Frequenz instabil zu bekommen, muß man sich schon sehr "bemühen". Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt. Christoph K. schrieb: > Oder kann ich die interne PLL mit dem externen Quarz locken? Was denn sonst? Was bedeutet denn PLL? Soll die etwa freilaufend agieren?
m.n. shrieb im Beitrag #6608716: > Wie bitte? > Um die PLL-Frequenz instabil zu bekommen, muß man sich schon sehr > "bemühen". Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt. Blabber keinen Stuß. Da gabe es schon 2012 immer wieder Probleme. Beitrag "STM32F207 Ethernet + RMII" http://lwip.100.n7.nabble.com/Low-Iperf-performance-of-lwip-1-4-1-on-STM32-and-FreeRTOS-td21579.html https://studio.segger.com/packages/STM32F2xx/CMSIS/Documents/DM00027213.pdf, Kapitel 2.8.6 Letzteres ist zwar für den F207, aber es war fraglich, ob der F407 da geändert wurde. Folglich hat das überhaupt nichts mit Abblockkondensatoren zu tun. Ich selbst betreibe ein Board mit F4, LAN8720 und RMII mit 150MHz, da paßt das mit den 50MHz, die aus der PLL nach Teilen durch 3 herauskommen. Aber viele benutzen lieber einen separaten Quarz, um nicht diese Probleme zu bekommen. Es empfiehlt sich also, sinnerfassend zu lesen: Wenn ich schreibe "Selbst mit HSE kann es für Ethernetanwendungen zuviel Jitter geben", dann ist das keine generelle Aussage, sondern das Wörtchen KANN hat hier eine einschränkende Bedeutung. Verstanden? Christoph K. schrieb: > Das wundert mich sehr. Wie kriegt man denn dann physikalisch exakte > Aussagen/Anwendungen hin, wenn die Zeitbasis nicht zuverlässig ist? Gar nicht.
m.n. schrieb: > Christoph K. schrieb: >> Oder kann ich die interne PLL mit dem externen Quarz locken? > > Was denn sonst? Was bedeutet denn PLL? Soll die etwa freilaufend > agieren? War ja auch meine ursprüngliche Annahme. Nur wunderte mich jetzt die Aussage von Jürgen S., ich könne den Quarz weglassen. Wenn er aber am PLL Kreis mitwirkt, wieso sehe ich keine Oszillation an PH0/PH1?
Christoph K. schrieb: > Wie kriegt man denn dann physikalisch exakte > Aussagen/Anwendungen hin, wenn die Zeitbasis nicht zuverlässig ist? Gar nicht. Deswegen hat der Chip Anschlüsse für einen Quarz. Es gibt aber Anwendungen, wo die Genauigkeit eines Quarzes nicht gebraucht wird.
Jürgen S. schrieb: > Letzteres ist zwar für den F207, aber es war fraglich, ob der F407 da > geändert wurde. F407 != F207 > Folglich hat das überhaupt nichts mit > Abblockkondensatoren zu tun. Es empfiehlt sich also, sinnerfassend zu lesen: Wenn ich schreibe "Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt.", dann ist das keine generelle Aussage, sondern das Wörtchen VIELLEICHT hat hier eine einschränkende Bedeutung. Verstanden? Jürgen S. schrieb: > Ich selbst betreibe ein Board mit F4, LAN8720 und RMII mit 150MHz, da > paßt das mit den 50MHz, die aus der PLL nach Teilen durch 3 > herauskommen. Geht doch ! ;-)
m.n. schrieb: > Es empfiehlt sich also, sinnerfassend zu lesen: Wenn ich schreibe > "Vielleicht klappt das, wenn man alle Abblock-Cs wegläßt.", > dann ist das keine generelle Aussage, sondern das Wörtchen VIELLEICHT > hat hier eine einschränkende Bedeutung. Verstanden? Das hättest Du wohl gerne: Der Jitter im F207 (und vielleicht auch F407) hat mit der PLL intern zu tun und nichts mit fehlenden oder vorhandenen "Abblockkondensatoren". So ein Quatsch. Christoph K. schrieb: > War ja auch meine ursprüngliche Annahme. Nur wunderte mich jetzt die > Aussage von Jürgen S., ich könne den Quarz weglassen. ? Entweder bist Du ein Troll oder Du hast noch nie was von Fehleranalyse gehört. Dazu würde auch passen, "auf Verdacht" den F103 auszulöten. Was soll das bezwecken? Ich habe überhaupt kein Interesse daran, daß Du mit dem HSI arbeitest. Eine Deiner Feststellungen war, daß Du ein Programm auf den F407 flashen kannst, das Programm dann aber nicht läuft. Aus diesem Grund ist es sinnvoll, zu testen, ob es an der Quarzbeschaltung liegt. Dazu ist ein Blinky ausreichend. Denn: Falls der Quarz oder Deine externe Clockerzeugung/-leitungsführung einen Schaden hat, würde das erklären, weshalb bei dem F407, den Du mit 5V malträtiert hattest, und bei dem neuen F407, denn Du nun draufgelötet hast, das Programm nicht läuft. Mit dem HSI müßte das dann gehen. Das ist alles. Einen Blinky zu programmieren, ist weniger Aufwand, als einen F103 abzulöten. Keiner will, daß Du auf den Quarz verzichtest. Warum Du zwanghaft noch immer an den PH0/PH1 rummessen willst, anstatt jeweils kurz einen Blinky mit HSI und einen Blinky mit HSE auszuprobieren, bleibt Dein Geheimnis. > Wenn er aber am PLL Kreis mitwirkt, wieso sehe ich keine Oszillation an > PH0/PH1? OMG. Was hat die PLL mit den Pins PH0/PH1 zu tun? Man sieht doch am Clockgenerator, daß da nichts auf PH0/PH1 zurückgeführt wird.
Angehängte Dateien:
Jürgen S. schrieb: >> Wenn er aber am PLL Kreis mitwirkt, wieso sehe ich keine Oszillation an >> PH0/PH1? > OMG. Was hat die PLL mit den Pins PH0/PH1 zu tun? Man sieht doch am > Clockgenerator, daß da nichts auf PH0/PH1 zurückgeführt wird. Ich meinte nicht PH0/PH1 auf der Steckerleiste, sondern PH0/PH1 am Chip(12/13). Wenn PLL mit Source=HSE arbeitet, dachte ich, da eine Oszillation sehen zu müssen, aber wahrscheinlich fließt nur ein kleiner Strom quer durch den Quarz und ich sehe keinen Spannungshub. Habe jetzt inzwischen eine Blinky-App mit STM32CubeIDE laufen. Clock so eingestellt wie Bild. Sie läuft im fabrikneuen, unmodifizierten Board, aber nicht in Boards B und C. Zur Erinnerung: Board A: nagelneues Board (MB997-D01, blauer Lötstopp) Board B: mein repariertes Board, wo Blinky-App.HEX aber nicht funktioniert Board C: "heiliges" Board mit der funktionierenden Anwendung Also Fazit im Moment: Board B: nach wie vor - auch nach Chipwechsel defekt. Board C: läuft nicht mit dem Blinky_HSE_PLL_168, läuft aber mit der Anwendung. Kann man STM32CubeIDE-Projekte hier posten oder exportieren?
Christoph K. schrieb: > Wenn PLL mit Source=HSE arbeitet, dachte ich, da eine > Oszillation sehen zu müssen, aber wahrscheinlich fließt nur ein kleiner > Strom quer durch den Quarz und ich sehe keinen Spannungshub. Stefan ⛄ F. schrieb zuvor im Beitrag #6606011: > Bei AVR konnte ich mit meinem Oszilloskop den Takt sichtbar machen, aber > nur an XTAL2 (das würde PH1 entsprechen) und nur wenn der Tastkopf auf > 1/10 eingestellt ist. Ansonsten belastet wer den Oszillator zu stark. Wollte mir ja keiner glauben. Stattdessen wurde ich blöd angemacht, hier meine Erfahrung mit AVR einfließen zu lassen.
Christoph K. schrieb: > Clock so > eingestellt wie Bild. was man auf dem Bild leider nicht sieht, ist die Einstellung ob xtal oder externer Clock. Das wird in Pinout Config // System Core // RCC ausgewählt. Wenn hier Bypass eingestellt ist, dann muss ein externer Clock kommen, auf den Nucleos vom F103 wenn die Brücken original sind. Wenn die Brücke auf ist, dann würde das Blinky bei den modifizierten Boards nicht laufen. Zum Gegentest das Blinky mit HSI bauen, das sollte dann auch bei den modifizierten Boards laufen.
Jürgen S. schrieb: > Das hättest Du wohl gerne: Der Jitter im F207 (und vielleicht auch F407) > hat mit der PLL intern zu tun und nichts mit fehlenden oder vorhandenen > "Abblockkondensatoren". So ein Quatsch. Es ist etwas lästig, aber damit sich hier keine Gerüchte verbreiten, muß ich Dir erneut widersprechen. Ein Blick ins Datenblatt zeigt, daß die interne PLL beim F407 von VDDA und VSSA versorgt wird. Sofern diese Spannung nicht sehr "sauber" ist, wird zwangsläufig Jitter in der PLL-Regelung entstehen. Für eine stabile PLL sind daher gerade an diesen Versorgungspins hinreichend Abblockkondensatoren vorzusehen.
Johannes S. schrieb: > Christoph K. schrieb: >> Clock so >> eingestellt wie Bild. > > was man auf dem Bild leider nicht sieht, ist die Einstellung ob xtal > oder externer Clock. Das wird in Pinout Config // System Core // RCC > ausgewählt. > Wenn hier Bypass eingestellt ist, dann muss ein externer Clock kommen, > auf den Nucleos vom F103 wenn die Brücken original sind. Wenn die Brücke > auf ist, dann würde das Blinky bei den modifizierten Boards nicht > laufen. > Zum Gegentest das Blinky mit HSI bauen, das sollte dann auch bei den > modifizierten Boards laufen. Es ist Crystal/Ceramic Resonator eingestellt, also nicht Bypass. Also müßte das Blinky_HSE_PLL_168 eigentlich laufen. R68 ist entfernt, es kommt also keine Clock vom MCO an.
m.n. schrieb: > Es ist etwas lästig, aber damit sich hier keine Gerüchte verbreiten, muß > ich Dir erneut widersprechen. Wenn Du Dich nicht entblöden kannst, ist das Dein Problem. Du willst also behaupten, daß man die PLL bei Vorhandensein der Abblockkondenstoren, die im Datenblatt angegeben sind, für Ethernet in jedem Fall verwenden kann? Dann täuschst Du Dich und andere, denn Du verbreitest Quatsch. Erstens hängt es davon ab, wie fehlertolerant der PHY hinsichtlich der clock (und hier war der DP83848 etwas zickig) ist, und zweitens, ob der PHY in RMII oder MII betrieben wird. RMII ist bezüglich der clock anfälliger. All das kann man nachlesen. Es gibt Leute, die gefiltert und abgeblockt haben bis zum Abwinken, die ein gutes Layout hatten, und trotzdem war der Jitter zu hoch. Deine Wortklauberei, Ehrenkäsigkeit und Rechthaberei kannst Du Dir übrigens dorthin stecken, wo es am dunkelsten ist. Du hast es nicht verkraftet, daß Dein Hinweis, daß der F407 die Clock im fabrikneuen Board vom MCO des F103 bekommt, so notwendig war wie ein Kropf -> "Herr Lehrer, ich weiß was". Doof, nichts dazugelernt und das wenige vergessen, sagt der Lehrer zu sowas. Johannes S. schrieb: > Zum Gegentest das Blinky mit HSI bauen, das sollte dann auch bei den > modifizierten Boards laufen. Vergiss es. Das macht der nicht, denn "es müßte ja mit dem Resonator laufen." Zum Glück kann man diesen bescheuerten Thread einfach links liegen lassen :)
Angehängte Dateien:
Jürgen S. schrieb: > > Johannes S. schrieb: >> Zum Gegentest das Blinky mit HSI bauen, das sollte dann auch bei den >> modifizierten Boards laufen. > Vergiss es. Das macht der nicht, denn "es müßte ja mit dem Resonator > laufen." Das würde ich gerne machen, aber dazu müßte ich verstehen, warum die gepostete Einstellung nicht funktionieren kann. Es ist doch eine gültige Clock-Einstellung. PLL-Clocksource mit Hilfe des Quarzes an PH0/PH1, HSE, so, wie die Einstellung von Board C (Anwendung), die ich ja auch in Assembler gepostet hatte. Grüße Christoph
Christoph K. schrieb: > Das würde ich gerne machen, aber dazu müßte ich verstehen, warum die > gepostete Einstellung nicht funktionieren kann. die gepostete Einstellung ist richtig, vorausgesetzt der µC ist ok und es ist ein Quarz angeschlossen. Quarz ist nach deiner Beschreibung ja vorhanden. Für HSI einfach den PLL Source Mux auf HSI stellen und Teiler M von 8 auf 4 runtersetzen.
Angehängte Dateien:
Nachtrag: habe jetzt HSI programmiert(Siehe Bild), Led blinkt auch nicht. Und blinkt auch nicht im Board A (Fabrikeinstellungen).
1 | void SystemClock_Config(void) |
2 | {
|
3 | RCC_OscInitTypeDef RCC_OscInitStruct = {0};
|
4 | RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
|
5 | |
6 | /** Configure the main internal regulator output voltage |
7 | */ |
8 | __HAL_RCC_PWR_CLK_ENABLE(); |
9 | __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1); |
10 | /** Initializes the RCC Oscillators according to the specified parameters |
11 | * in the RCC_OscInitTypeDef structure. |
12 | */ |
13 | RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE; |
14 | RCC_OscInitStruct.HSEState = RCC_HSE_ON; |
15 | RCC_OscInitStruct.HSIState = RCC_HSI_ON; |
16 | RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT; |
17 | RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; |
18 | RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; |
19 | RCC_OscInitStruct.PLL.PLLM = 8; |
20 | RCC_OscInitStruct.PLL.PLLN = 336; |
21 | RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; |
22 | RCC_OscInitStruct.PLL.PLLQ = 4; |
23 | if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) |
24 | {
|
25 | Error_Handler(); |
26 | } |
27 | /** Initializes the CPU, AHB and APB buses clocks |
28 | */ |
29 | RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK |
30 | |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2; |
31 | RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI; |
32 | RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1; |
33 | RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4; |
34 | RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV4; |
35 | |
36 | if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK) |
37 | {
|
38 | Error_Handler(); |
39 | } |
40 | HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_PLLCLK, RCC_MCODIV_1); |
41 | } |
(Hatte Beitrag von Johannes noch nicht gelesen, als ich das postete)
:
Bearbeitet durch User
Angehängte Dateien:
So? Was bringt da der Teiler M, wenn nicht rot markierte Felder? Sorry, meine Posts hinsichtlich nicht funktionierenden Blinkens bitte ignorieren. Ich hatte beim Projektkopieren übersehen, daß der User-Code im main.c vom IDE gelöscht wurde.
:
Bearbeitet durch User
Sorry, ist noch zu früh zum Rechnen. Doppelte f bedeutet natürlich auch doppelt so großer Teiler, also 16 wenn es erlaubt ist.
Angehängte Dateien:
Stand im Moment der (obige Clock-Konfiguration): Board A (fabrikneu, unmodifiziert): Blinky läuft Board B (vermeintlich repariert und modifiziert): Led geht an und bleibt an. nach Reset aus. Board C (intakt und modifiziert): gleiches Verhalten wie B (habe R42 bei den modifizierten Boards wieder eingelötet, damit ich was "sehe") in der Anwendung hängt da auch eine LED dran). Ich betreibe die Boards aber im Moment "in der Luft", also nicht in die Schaltung eingesteckt. Übrigens, interessante Beobachtung: Wenn ich ins Programm hineinsteppe, crasht es im HAL_DELAY(500). (s.Bild)
:
Bearbeitet durch User
dann würde ich sagen liegt es am schon oft diskutierten Boot0, SB18. Wenn der offen ist, dann läuft der nach dem Start in den Bootloader und nicht in dein Blinky.
Johannes S. schrieb: > dann würde ich sagen liegt es am schon oft diskutierten Boot0, SB18. > Wenn der offen ist, dann läuft der nach dem Start in den Bootloader und > nicht in dein Blinky. Steppt aber ins main.c bis hinter das 1. Setzen der LED und verschwindet dann im HAL_DELAY.
Ich weis ja nicht, ob das bei den Discery-Boards anders gelöst ist (würde mich aber wundern), aber bei allen mir bekannten Nucleo-Boards haben die MCU keinen eigenen Quarz, und beziehen ihren Takt (i.d.R. 8MHz) aus dem Debugger. HSE muß in dem Fall also auf "Bypass" gestellt werden.
:
Bearbeitet durch User
das ist bei den Discos anders, die haben ihren eigenen Quarz, wurde schon geklärt.
Faszinierend finde ich, dass hier immer noch modifizierte Boards diskutiert wird, ohne die Modifikationen zu kennen. Das Thema läuft ja schon länger, nicht erst seit 26. Februar. Da muss ich mich schon fragen, ob das ganze mutwillige Trollerei ist oder ob hier jemand wirklich ein Problem lösen will.
Stefan ⛄ F. schrieb: > Faszinierend finde ich, dass hier immer noch modifizierte Boards > diskutiert wird, ohne die Modifikationen zu kennen. Das Thema läuft ja > schon länger, nicht erst seit 26. Februar. > > Da muss ich mich schon fragen, ob das ganze mutwillige Trollerei ist > oder ob hier jemand wirklich ein Problem lösen will. Ich habe die Modifikationen hier in diesem Thread schon lange gepostet. (3.3.2021, 17.17). Und auch in dem anderen Thread hatte ich sie gepostet.
:
Bearbeitet durch User
Christoph K. schrieb: > Ich habe die Modifikationen hier in diesem Thread schon lange gepostet. In kaum nachvollziehbarer Form. Vor allem weil du die ganze Zeit vom HSE Oszillator und Quarz geschrieben hast, ohne einen Quarz eingesetzt zu haben. Da passen schon deine eigenen Infos nicht zusammen. Ein Schaltplan wäre hier wesentlich hilfreicher.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Ich habe die Modifikationen hier in diesem Thread schon lange gepostet. > > In kaum nachvollziehbarer Form. Vor allem weil du die ganze Zeit vom HSE > Oszillator und Quarz geschrieben hast, ohne einen Quarz eingesetzt zu > haben. Da passen schon deine eigenen Infos nicht zusammen. > > Ein Schaltplan wäre hier wesentlich hilfreicher. Schaltplan ist der aus dem ST UM1472 mit den beschriebenen Mods. Wieso nicht nachvollziehbar? Ich habe die Clockkonfiguration der Anwendung gepostet. Die ist HSE/PLL. Dann sagt mir jemand, er sage nichts, bevor ich nicht ein Blinky mit HSI zum Laufen gebracht habe. Da sind wir jetzt.
Christoph K. schrieb: > Schaltplan ist der aus dem ST UM1472 mit den beschriebenen Mods. Soll ich mit den jetzt ausdrucken und dann die Textuellen Anmerkungen einzeichnen? Was mit dem Quarz ist (um den sich hier alles dreht), weiß ich dann immer noch nicht. Abgesehen davon: Das ist deine Hausaufgabe. > Ich habe die Clockkonfiguration der > Anwendung gepostet. Die ist HSE/PLL. Ohne Quarz, ohne Bypass -> Kann nicht funktionieren. Gehen sie zurück aus Los.
Johannes S. schrieb: > dann würde ich sagen liegt es am schon oft diskutierten Boot0, SB18. > Wenn der offen ist, dann läuft der nach dem Start in den Bootloader und > nicht in dein Blinky. Danke, das war's tatsächlich, daß jetzt der Blinky nicht lief. Habe BOOT0 auf GND gelegt und das Blinky läuft jetzt. Stand der: Board B (das mit dem ausgewechselten Chip) läuft mit HSI-Blinky.
Stefan ⛄ F. schrieb: > Ohne Quarz -> Kann nicht funktionieren. du nervst und müllst den Thread voll. Das Disco1 hat einen Quarz. Und trotzdem wird gerade erstmal HSI getestet. Habe hier gerade an einem F411 Blackpill getestet, wenn ich Boot0 auf high halte kann ich auch nicht debuggen. Das Disco hat den Boot0 rausgeführt, Brücke nach GND dran und probieren, nicht wieder neuen Nebenkriegsschauplatz aufmachen. -> ok, geklärt.
nächster Schritt wäre dann wieder mit HSE (evtl. erst ohne PLL). Aber vermutlich war dann auch hier Boot0 das 'Problem'.
Johannes S. schrieb: > Stefan ⛄ F. schrieb: >> Ohne Quarz -> Kann nicht funktionieren. > > du nervst und müllst den Thread voll. Das Disco1 hat einen Quarz. Und > trotzdem wird gerade erstmal HSI getestet. > Sag' mal, liest Du eigentlich nicht? Ausgangpunkt dieses Threads war doch der, daß ich ein Board repariert habe, das aber jetzt nicht so läuft, wie es soll. Da es auf HSE/PLL programmiert ist, war die Vermutung, daß was mit dem Quarz sein könne oder mit der Schaltung in dem Bereich. Es sollte also erst einmal ein Blinky mit HSI zum Laufen gebracht werden. Das ist jetzt - mit ein paar Hindernissen - erreicht. Jetzt kann ich mich wieder der Frage zuwenden, ob mein repariertes Boar vielleicht noch einen Fehler hat, der bewirkt, daß der UART beim Starten der Anwendung nichts ausgibt, während das Board C (heiliges Anwendungsboard) diesbezüglich funktioniert. So, da sind wir jetzt.
:
Bearbeitet durch User
Angehängte Dateien:
Johannes S. schrieb: > Das Disco1 hat einen Quarz. Kritik angenommen, ich habe es mit den Nucleo Board verwechselt.
Christoph K. schrieb: > Johannes S. schrieb: >> Stefan ⛄ F. schrieb: >>> Ohne Quarz -> Kann nicht funktionieren. >> >> du nervst und müllst den Thread voll. Das Disco1 hat einen Quarz. Und >> trotzdem wird gerade erstmal HSI getestet. > Sag' mal, liest Du eigentlich nicht? Hatte den Autor verwechselt. Sorry. HSE 8MHz (no PLL) -> Blinky läuft
:
Bearbeitet durch User
dann würde ich den verdächtigen USART in das Blinky einbauen und da etwas ausgeben. Geht für einen quick&dirty Test auch einfach mit CubeMX. Beim Umlöten der Chips könnte da auch eine Verbindung Chip-Header kaputt sein.
8MHz HSE-PLL läuft auch. Mache jetzt den UART Test.
:
Bearbeitet durch User
Christoph K. schrieb: > 8MHz HSE-PLL läuft auch. Mache jetzt den UART Test. UART3 Tx läuft- Kann "hello world" rausschreiben. Muß jetzt sehen, ob Rx auch funktioniert, denn die Anwedungssoftware wartet erst auf ein Zeichen, bevor sie was ausgibt.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.