I have a Discovery F4 Board and purchased recently a China Board from *bay (http://www.ebay.at/itm/STM32F407VGT6-ARM-Cortex-M4-32bit-MCU-Core-Development-Board-STM32F4-Discovery-/272501820584?) with the same uC (STM32F407VGT6). I thought a cheap way to test my code and put it into my project. I have a sample code which works on the Discovery and i flashed the code with my Nucleo Board as programmer into the China Board which was a success. I tried two ways, first the SWD Header on the Nucleo like here: (https://developer.mbed.org/questions/7974/F401RE-Cut-off-ST-LINK/) i also soldered a cable to the RESET Pin and connected it to the Nucleo Header Pin 5. I flashed with ST Link utility, read back and compared - no differences. Second i put a jumper on BOOT1 (BOOT0 and BOOT1 have Pullups) which pulled it low and entered the Bootloader, flashed with ST Flash Loader over UART1 which also worked (read back and compared). I then put a second jumper on BOOT0 - so both BOOT Pins are LOW, and the uC SHOULD start from Flash - but nothing. I am really stumped because i searched a lot and it should work. The code is definetely working, it is in the flash memory, the uC is alive through the SWD interface (i can see the Device, DeviceID, RevisionID,.. in the ST Link Utility) the Revision corresponds with the Chip (it is 2.0). Anybody any tips???
Gast
#4951529
Robert O. schrieb: > Anybody any tips? Yes. At the very first: do not simply write a random firmware into a controller. The firmware must be developed for the actual controller in it's actual environment. So edit your firmware, adapt it to the changed environment and pin usage and recompile it. Next: check the different BOOTx pins. To start the firmware and not start the bootloader, the BOOTx-Pins need to be set according to the manual. So read it carefully. Also check the clock generation. For the very first checks you can leave the clock as it is after Reset. Let something toggle, so you can see with your oscilloscope, if this occurs or not. Also you have on all types a port pin, where you can see the actual system clock (or this clock div by 2) on your oscilloscope. W.S.
Gast
#4951852
Schreibt doch einfach in Eurer Muttersprache. Dann wird das Problem verständlicher ;-)
Gast
#4951908
Clock könnte eine gute Idee sein. Weiß jemand, was da als Quarz für HSE verbaut ist? Den Uhrenquarz kann man ja erkennen. ;-)
Gast
#4951917
noreply@noreply.com schrieb: > Weiß jemand, was da als Quarz für HSE verbaut ist? Ganz standardmässig wie auf den Discovery Boards: 8 MHz.
Gast
#4951937
STM STM STM schrieb im Beitrag #4951917: > noreply@noreply.com schrieb: >> Weiß jemand, was da als Quarz für HSE verbaut ist? > > Ganz standardmässig wie auf den Discovery Boards: 8 MHz. Siehst Du den Schaltplan irgendwo? Laut Beschreibung läuft das Teil mit internem Takt, was natürlich in die Hose geht, wenn die Datei "system_stm32f4xx.c" verwendet wird, die einen externen Takt voraussetzt.
Gast
#4951949
m.n. schrieb: > Laut Beschreibung läuft das Teil mit internem Takt Käse. Die Artikelbeschreibung gibt nur allgemein das wieder was der STM sowieso kann, keine Board-spezifischen Eigenschaften. m.n. schrieb: > Siehst Du den Schaltplan irgendwo? Das kleine Päckchen gleich neben dem 32KHz Quarz.
Gast
#4951952
STM STM STM schrieb im Beitrag #4951917: > Ganz standardmässig wie auf den Discovery Boards: 8 MHz. Sie nochmal nach, da ist keiner.
Gast
#4951961
Horst schrieb: > Sie nochmal nach, da ist keiner. Wenn man keine Ahnung hat, einfach mal die ..... Das mit rotem Pfeil markierte Teil ist ein Quarz oder ein keramischer Resonator.
Angehängte Dateien:
-
Quarz_oder_Resonator.jpg
(51 KB)
Gast
#4951966
m.n. schrieb: > Siehst Du den Schaltplan irgendwo? Nö. Habe im Netz nichts gefunden.
Gast
#4951970
noreply@noreply.com schrieb: > m.n. schrieb: >> Siehst Du den Schaltplan irgendwo? > > Nö. Habe im Netz nichts gefunden. Tja, dann sollte sich der TO noch einmal konkret dazu äußern. "Bilderrätsel" ersetzen keinen Schaltplan.
Gast
#4951977
m.n. schrieb: > "Bilderrätsel" ersetzen keinen Schaltplan. Ja lieber hier bisschen runlabern anstatt die Fakten zu erkennen .... Auf dem Board ist de facto nichts drauf was einem Rätsel aufbürden könnte: - Nackter Prozessor, alle Pins herausgeführt - 3V3 Spannunsregler - Uhrenquarz und System-Quarz - Abblock-Kondensatoren - Pullup/Pulldowns für die Boot Pins und für Reset - Reset-Knopf Oder so: "Ach nee, dafür brauch ich aber schon einen ausführlichen Schaltplan sonst komme ich nicht weiter"
Gast
#4951980
@m.n. Da ist nicht viel drauf. Erste kurze Analyse. - USB meldet sich nicht am PC. - wahrscheinlich Spannungswandler mit LED als Ein-Anzeige bei Versorgung über USB. - "Schwinger" für HSE - 32.678 Quarz für LSE - Boot0/Boot1 siehe oben. - Zwei Taster. ?Reset und ? Eingabebutton. - Diverse Pufferkondensatoren für die CPU. Wie W.S. vorgeschlagen hat. Mit einem Bare-Metal-Ansatz erst mal eine Led zum Blinken bringen.
Gast
#4951982
Ja, ja. Alles ist in Ordnung, nur funktioniert es nicht. Mit "alternativen Schaltplänen" kann ich nichts anfangen.
Gast
#4951986
noreply@noreply.com schrieb: > - "Schwinger" für HSE Dann kontrollieren, ob HSE auch vorhanden ist.
Gast
#4951988
m.n. schrieb: > Mit "alternativen Schaltplänen" kann ich nichts anfangen. Mit Beamten mit Beamten-Mentalität kann ich nichts anfangen.
Gast
#4952042
Ich würde zum probieren HSE 8MHz einstellen und direkt an MCO leiten und messen. Wenn was ankommt, je nach Frequenzabweichung Quarz oder Resonator. Wenn nicht 16, 25 MHz einstellen.
Gast
#4952093
Laut Ebay-Artikelbeschreibung spielt der interne RC-Oszillator mit 16MHz.
Gast
#4952098
pegel schrieb: > Ich würde zum probieren HSE 8MHz einstellen Der TO ist offensichtlich kein Deutsch-Sprachiger und kann mit eueren Hinweisen wenig anfangen. Robert O. schrieb: > Anybody any tips??? Bereits die erste Antwort dieses Threads von W.S. zeigt meiner Meinung nach wo es hingeht, aber der TO ist wohl schon längst auf und davon. W.S. schrieb: > do not simply write a random firmware into a controller. STK500-Besitzer schrieb: > Laut Ebay-Artikelbeschreibung spielt der interne RC-Oszillator mit > 16MHz. Das ist ein sehr wertvoller Hinweis (oder doch was anderes?). Danke dafür. Das steht in jedem STM-Datenblatt für Mikrocontroller drin.
Gast
#4952118
STM STM STM schrieb im Beitrag #4952098: > Der TO ist offensichtlich kein Deutsch-Sprachiger und kann > mit eueren Hinweisen wenig anfangen. So, so; hier ging es noch: Beitrag "[XMega][C] Flash Write möglich aus Anwendung?"
Gast
#4952124
STM STM STM schrieb im Beitrag #4951949: > m.n. schrieb: >> Laut Beschreibung läuft das Teil mit internem Takt > > Käse. STM STM STM schrieb im Beitrag #4952098: > STK500-Besitzer schrieb: >> Laut Ebay-Artikelbeschreibung spielt der interne RC-Oszillator mit >> 16MHz. > > Das ist ein sehr wertvoller Hinweis (oder doch was anderes?). > Danke dafür. Erst Käse dann Danke?
Gast
#4952125
m.n. schrieb: > So, so; hier ging es noch: Ja dann braucht er diese Hinweise in diesem Thread auch gar überhaupt nicht.
Na, da hat sich ja doch etwas getan. Einmal danke für die Antworten. Zum Thema (in chronologischer Reihenfolge): Die firmware war für den Controller, am Discovry ist die selbe Type drauf im selben Package. Auch die BOOT pins wurden kontrolliert. Habe ich jedoch alles geschrieben - wenn auch in Englisch. Ich dachte damit erreiche ich eine größere Leserschicht. Quarz ist ein 8MHz SMD Quarz oben - die selbe Frequenz wie am Discovery. Schaltplan habe reverse engineered, da sind aber keine Besonderheiten wie auch schon erwähnt. Was ich nicht verstehe: Der Controller kann über SDW UND den internen Bootloader programmiert werden, selbst ohne Fachwissen kann ich logisch erkennen dass ein Takt da sein muss (wegen er UART verbindung des Bootloader). Meine konkrete Frage: Gibt es beim ARM Fuses wie beim Atmel Mega oder passiert die Clock einstellung AUSSCHLIEßLICH in Software? Da die Firmware funktioniert kann eigentlich nur der Quarz eine andere Frequenz haben (es steht 8 oder 80 drauf - was mich vermuten lässt dass es sich um 8MHz handelt). Ich werde versuchen ihn nachzumessen. Ansonsten kann ich mir nicht erklären warum das nicht funktioniert. Falls jemand nützliche Tips hat würde ich mich freuen.
Gast
#4952196
@Robert Offner, Welche Firmware? Was funktioniert? Was funktioniert nicht? Mein nächster Schritte wäre, das Beispiel in libopencm3 für das STM32F4Discovery für eine blinkende LED auszuprobieren, wenn ich viel Zeit hätte. ;-)
Gast
#4952205
Robert O. schrieb: > Gibt es beim ARM Fuses wie beim Atmel Mega oder > passiert die Clock einstellung AUSSCHLIEßLICH in Software? Na da kann ich mir den üblichen Hinweis auf STM32CubeMX nicht mehr verkneifen.
Angehängte Dateien:
-
CubeMX_F407.png
(110 KB)
Gast
#4952227
Robert O. schrieb: > Meine konkrete Frage: Gibt es beim ARM Fuses wie beim Atmel Mega oder > passiert die Clock einstellung AUSSCHLIEßLICH in Software? Schon mal versucht ein Datenblatt zu lesen? --------------------------------------------------------- 2.2.12 Clocks and startup On reset the 16 MHz internal RC oscillator is selected as the default CPU clock. The 16 MHz internal RC oscillator is factory- trimmed to offer 1% accuracy over the full temperature range. The application can then select as system clock either the RC oscillator or an external 4-26 MHz clock source. This clock can be monitored for failure. If a failure is detected, the system automatically switches back to the internal RC oscillator and a software interrupt is generated (if enabled). This clock source is input to a PLL thus allowing to increase the frequency up to 168 MHz. Similarly, full interrupt management of the PLL clock entry is available when necessary (for example if an indirectly used external oscillator fails). ---------------------------------------------------------
Gast
#4952236
noreply@noreply.com schrieb: > wenn ich viel Zeit hätte. ;-) Hab viel Zeit und Spass dran. LED ist an PE0 wenn ich das richtig sehe. An PA8 kommt der HSE Takt an.
Jetzt schreibe ich eh schon deutsch und trotzdem versteht mich keiner. Was bitte hat ein Bild vom Clocktree aus Cube bitte für einen Sinn und wie kann ich das als Antwort auf meine Frage verstehen? Ich werde heute noch einmal eine andere firmware ausprobieren die nur eine LED blinken lässt. Mit libopencm habe ich mich schon einmal beschäftigt bin aber nicht weitergekommen. Verwende jetzt Chibios. Die blinkende led habe ich aber noch mit standard peripheral lib oder cube weiss nicht mehr so genau. Welcher Pin ist denn der wo die System clock herauskommt? Ein Post ist doch nicht gänzlich unnötig. Da heisst es: "If a failure is detected, the system automatically switches back to the internal RC oscillator" Es könnte also sein dass der externe Quarz ein Problem hat (kalte Lötstelle, mechanischer defekt, falsche kondensatoren,...) und die CPU auf den internen 16MHz RC oszillator umschaltet. Aber was passiert dann? Da ja der externe Takt ausgewählt ist steht dann die CPU oder läuft sie dann mit 16MHz? Schaltet der System Clock MUX automatisch um? Wie bereits geschrieben ich werde noch eine andere firmware probieren und die Ergebnisse posten. Danke soweit für alle hilfreichen Antworten. Super, während des Schreibens ist ja noch einiges gekommen. (der Vorschau Button hat ja doch sinn:) ). Das bin file werde ich gleich nach dem essen flashen - Danke dafür.
Gast
#4952250
Robert O. schrieb: > Ich werde heute noch einmal eine andere firmware ausprobieren die nur > eine LED blinken Guck mal einen Post hoch. Da war jemand so nett, und hat schon ein bin geliefert. ;-) Könnte funktionieren. :-)
Gast
#4952263
Robert O. schrieb: > Was bitte hat ein Bild vom Clocktree aus Cube bitte für einen Sinn und > wie kann ich das als Antwort auf meine Frage verstehen? Soll bedeuten das es sehr komfortabel eingestellt werden kann und dann in die Software übernommen wird. Ohne Fuses.
Leider keine Funktion. Habe ein anderes binary geflasht da das Blinky.bin leider auch nicht funktioniert hat (getestet mit meinem discovery). Habe den Verkäufer angeschrieben und ihn um ein neues Board gebeten. Mal sehen was passiert.
Gast
#4952472
Das ist schlecht. Ich habe so ein Problem mit ein paar Mini F103 Boards. Da lässt sich einfach der 32kHz LSE nicht starten. Zum Abschluss biete ich dir noch eine bin die den HSI benutzt. Am PA8 kommen dann 16MHz an, wenn es läuft.
Danke für das .bin. Habe es geflasht und es funktioniert nicht (mit dem discovery schon - PE0 blinkt mit 1Hz und an PA8 kommen 16MHz). Danke für die Mühe aber das Board hat wohl ein gröberes Problem.
Hallo Zusammen, hier ist der Schaltplan für das besagte Board ... Viele Grüße Klaus Skibowski
Gast
#4955301
Klaus S. schrieb: > hier ist der Schaltplan für das besagte Board ... Ein fehlender interner Reset könnte das Problem sein. PDR_ON ist nicht eindeutig beschaltet. Der Pin sollte auf GND liegen. Die Beschaltung OSC_IN und OSC_OUT ist auch nicht ganz klar. Keramischer Resonator unbekannter Frequenz mit unbekanntem Wert? Egal.
Beitrag #4955329 wurde von einem Moderator gelöscht.
Gast
#4955426
Klaus S. schrieb: > hier ist der Schaltplan für das besagte Board ... Danke. Hinweis: C22 und C23 sind nie und nimmer 2.2 uF. Siehe Foto. 2.2 uF wäre recommended laut Datenblatt. Da kann ja mal jemand schätzen, der sich auskennt. Ich habe mal Keramikkondensatoren parallel dazu gelötet. Keine Verbesserung. Ich kann die Kapazität aber auch nur schätzen.
Gast
#4955453
noreply@noreply.com schrieb: > Siehe Foto. Welches Foto? noreply@noreply.com schrieb: > Da kann ja mal jemand schätzen, der sich auskennt. Ich kenn mich damit aus. 2.2uF gibt es locker im Format 0402 als kermischen Kondensator. noreply@noreply.com schrieb: > Ich habe mal Keramikkondensatoren parallel dazu gelötet. Hast du das gleiche Board, oder bist du selbst der TO, Robert Offner?
Gast
#4955459
STM STM STM schrieb im Beitrag #4955453: > Hast du das gleiche Board, oder bist du selbst der TO, Robert Offner? Das frage ich mich auch gerade. Sind denn R6 und R7 bestückt und haben jeweils 0 Ohm? Das wäre dann ein schöner Kurzschluß. China-Kram eben.
Gast
#4955470
STM STM STM schrieb im Beitrag #4955453: > Hast du das gleiche Board, oder bist du selbst der TO, Robert Offner? Bilder über die Angebote. Ich habe ein ähnliches Board. Anderer Lieferant. Bilder werden von Verkäufern gleich verwendet. Aber mein Board hat einen eher schwarzen Überzug. Ich habe ein STM32F3-Discovery. Die haben 2.2 uF Tantal-Kondensatoren verbaut. Da ist locker eine Zehnerpotenz Volumenunterschied zu den gelieferten Board.
Gast
#4955475
STM STM STM schrieb im Beitrag #4951977: > m.n. schrieb: >> "Bilderrätsel" ersetzen keinen Schaltplan. > > Ja lieber hier bisschen runlabern anstatt die Fakten zu > erkennen .... Na? Einen (Schalt-)plan ist wohl doch nicht so beamtenmäßig schlecht? ;-)
Gast
#4955491
@STM STM STM, danke für den Hinweis mit der 0402-er Bauform. Gibt es in der Kapazität und Spannungslage und könnten verbaut sein. Gegebenenfalls müßte jemand mit Meßgeräten ran. Ich bin Grobmotoriker. ;-)
Gast
#4955492
m.n. schrieb: > Na? Einen (Schalt-)plan ist wohl doch nicht so beamtenmäßig schlecht? Gut dass du dein Beamtendenken es endlich zugibst, Beamter. Auch die Chinesen testen ihre Boards vor Auslieferung, ich behaupte mal dass unser diskutiertes Board prinzipiell voll in Ordnung ist. Selbst der besagte Pullup/Pulldown ist einseitig nicht bestückt, also alles im roten Bereich (wollte ich grün sagen?).
Gast
#4955495
noreply@noreply.com schrieb: > Ich bin Grobmotoriker. ;-) ... und Robert Offner.
Gast
#4955511
STM STM STM schrieb im Beitrag #4955495: > noreply@noreply.com schrieb: >> Ich bin Grobmotoriker. ;-) > > ... und Robert Offner. Nein. Ich habe nur ein gleiches Board.
Gast
#4955516
noreply@noreply.com schrieb: > Keine Verbesserung. Gegenüber welchem Zustand?
Gast
#4955609
STM STM STM schrieb im Beitrag #4955516: > noreply@noreply.com schrieb: >> Keine Verbesserung. > > Gegenüber welchem Zustand? Gegenüber den oben beschriebenen Zustand (Ich komme mit dem openocd auf den Chip. Ich sehe Flash. Kann Flash schreiben bzw. wieder lesen. LED blinkt nicht.) von Robert Offner. Delta zwischen den STM32F(3,4)-Discovery und dem gelieferten Board waren die Ausführung der Kondensatoren für die internen Spannungsregler. Vielen Dank für die Hilfe. Ich muß jetzt aber erstmal um meine STM32F030F4P6 Demoboards kümmern. Die funktionieren. ;-)
Gast
#4955632
noreply@noreply.com schrieb: > Gegenüber den oben beschriebenen Zustand Wo ist der "oben beschriebene Zustand", wo ist "oben"? Alles sehr vage, für viel Phantasie ....
Gast
#4955658
STM STM STM schrieb im Beitrag #4955632: > Wo ist der "oben beschriebene Zustand", wo ist "oben"? Alles > sehr vage, für viel Phantasie .... Beitrag 1 Startbeitrag dieses Threads. Hier habe ich es nochmal beschrieben. noreply@noreply.com schrieb: > Gegenüber den oben beschriebenen Zustand (Ich komme mit dem openocd auf > den Chip. Ich sehe Flash. Kann Flash schreiben bzw. wieder lesen. LED > blinkt nicht.) von Robert Offner.
Gast
#4955663
noreply@noreply.com schrieb: > Gegenüber den oben beschriebenen Zustand (Ich komme mit dem openocd auf > den Chip. Ich sehe Flash. noreply@noreply.com schrieb: > Beitrag 1 Startbeitrag dieses Threads. Das ist also dein Zustand. Daraus ist aber doch zu folgern: Robert Offner = noreply@noreply.com
STM STM STM schrieb im Beitrag #4955663: > Das ist also dein Zustand. Ja, das ist auch sein Zustand. > Daraus ist aber doch zu folgern: Robert Offner = noreply@noreply.com Die Folgerung ist nicht schlüssig. Ich kann das als Moderator auch nahezu ausschließen. Wir haben es hier mit zwei Leuten zu tun, die dasselbe Problem haben. Wie ich es verstehe: noreply hat das Problem von Robert Offner reproduzieren können. Bitte wieder zum Thema kommen.
Gast
#4955888
Frank M. schrieb: > Bitte wieder zum Thema kommen. Na dann noch einmal explizit gefragt: Ist R6 oder ist R7 bestückt? PDR_ON, BOOT0 und BOOT1 müssen auf GND liegen.
Gast
#4955898
Ist doch ganz einfach: R7 geht nach Masse und ist nicht bestückt. Die Boot Pins darf man selbst jumpern nach eigenem gusto. Default-mässig wären sie aber auf 1, 1. Das ist nicht gut...
Angehängte Dateien:
-
PDR_ON.jpg
(180 KB)
Gast
#4955915
STM STM STM schrieb im Beitrag #4955898: > R7 geht nach Masse und ist nicht bestückt. Beim Discovery-Board ist Pin99 auf GND.