STM32F407VGT6 China Board not working Tips?

[Robert O. (rob_o)]

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???

[W.S. (Gast)]

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.

[m.n. (Gast)]

Schreibt doch einfach in Eurer Muttersprache. Dann wird das Problem 
verständlicher ;-)

[[e-mail] (Gast)]

Clock könnte eine gute Idee sein. Weiß jemand, was da als Quarz für HSE 
verbaut ist? Den Uhrenquarz kann man ja erkennen. ;-)

[STM STM STM (Gast)]

[e-mail] schrieb:
> Weiß jemand, was da als Quarz für HSE verbaut ist?

Ganz standardmässig wie auf den Discovery Boards: 8 MHz.

[m.n. (Gast)]

STM STM STM schrieb:
> [e-mail] 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.

[STM STM STM (Gast)]

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.

[Horst (Gast)]

STM STM STM schrieb:
> Ganz standardmässig wie auf den Discovery Boards: 8 MHz.

Sie nochmal nach, da ist keiner.

[STM STM STM (Gast)]

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.

[[e-mail] (Gast)]

m.n. schrieb:
> Siehst Du den Schaltplan irgendwo?

Nö. Habe im Netz nichts gefunden.

[m.n. (Gast)]

[e-mail] 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.

[STM STM STM (Gast)]

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"

[[e-mail] (Gast)]

@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.

[m.n. (Gast)]

Ja, ja. Alles ist in Ordnung, nur funktioniert es nicht.
Mit "alternativen Schaltplänen" kann ich nichts anfangen.

[m.n. (Gast)]

[e-mail] schrieb:
> - "Schwinger" für HSE

Dann kontrollieren, ob HSE auch vorhanden ist.

[STM STM STM (Gast)]

m.n. schrieb:
> Mit "alternativen Schaltplänen" kann ich nichts anfangen.

Mit Beamten mit Beamten-Mentalität kann ich nichts anfangen.

[pegel (Gast)]

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.

[STK500-Besitzer (Gast)]

Laut Ebay-Artikelbeschreibung spielt der interne RC-Oszillator mit 
16MHz.

[STM STM STM (Gast)]

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.

[m.n. (Gast)]

STM STM STM schrieb:
> 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?"

[m.n. (Gast)]

STM STM STM schrieb:
> m.n. schrieb:
>> Laut Beschreibung läuft das Teil mit internem Takt
>
> Käse.

STM STM STM schrieb:
> 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?

[STM STM STM (Gast)]

m.n. schrieb:
> So, so; hier ging es noch:

Ja dann braucht er diese Hinweise in diesem Thread auch
gar überhaupt nicht.

[Robert O. (rob_o)]

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.

[[e-mail] (Gast)]

@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. ;-)

[pegel (Gast)]

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.

[STM STM STM (Gast)]

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).
---------------------------------------------------------

[pegel (Gast)]

[e-mail] 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.

[Robert O. (rob_o)]

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.

[[e-mail] (Gast)]

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. :-)

[pegel (Gast)]

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.

[Robert O. (rob_o)]

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.

[pegel (Gast)]

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.

[Robert O. (rob_o)]

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.

[Klaus S. (skibby)]

Hallo Zusammen,
hier ist der Schaltplan für das besagte Board ...

Viele Grüße
Klaus Skibowski

[m.n. (Gast)]

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.

[[e-mail] (Gast)]

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.

[STM STM STM (Gast)]

[e-mail] schrieb:
> Siehe Foto.

Welches Foto?

[e-mail] 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.

[e-mail] schrieb:
> Ich habe mal Keramikkondensatoren parallel dazu gelötet.

Hast du das gleiche Board, oder bist du selbst der TO, Robert Offner?

[m.n. (Gast)]

STM STM STM schrieb:
> 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.

[[e-mail] (Gast)]

STM STM STM schrieb:
> 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.

[m.n. (Gast)]

STM STM STM schrieb:
> 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? 
;-)

[[e-mail] (Gast)]

@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. ;-)

[STM STM STM (Gast)]

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?).

[STM STM STM (Gast)]

[e-mail] schrieb:
> Ich bin Grobmotoriker. ;-)

... und Robert Offner.

[[e-mail] (Gast)]

STM STM STM schrieb:
> [e-mail] schrieb:
>> Ich bin Grobmotoriker. ;-)
>
> ... und Robert Offner.

Nein. Ich habe nur ein gleiches Board.

[STM STM STM (Gast)]

[e-mail] schrieb:
> Keine Verbesserung.

Gegenüber welchem Zustand?

[[e-mail] (Gast)]

STM STM STM schrieb:
> [e-mail] 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. ;-)

[STM STM STM (Gast)]

[e-mail] schrieb:
> Gegenüber den oben beschriebenen Zustand

Wo ist der "oben beschriebene Zustand", wo ist "oben"? Alles
sehr vage, für viel Phantasie ....

[[e-mail] (Gast)]

STM STM STM schrieb:
> 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.

[e-mail] 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.

[STM STM STM (Gast)]

[e-mail] schrieb:
> Gegenüber den oben beschriebenen Zustand (Ich komme mit dem openocd auf
> den Chip. Ich sehe Flash.

[e-mail] schrieb:
> Beitrag 1 Startbeitrag dieses Threads.

Das ist also dein Zustand.
Daraus ist aber doch zu folgern:  Robert Offner = [e-mail]

[Frank M. (ukw) (Moderator)]

STM STM STM schrieb:
> Das ist also dein Zustand.

Ja, das ist auch sein Zustand.

> Daraus ist aber doch zu folgern:  Robert Offner = [e-mail]

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.

[m.n. (Gast)]

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.

[STM STM STM (Gast)]

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...

[m.n. (Gast)]

STM STM STM schrieb:
> R7 geht nach Masse und ist nicht bestückt.

Beim Discovery-Board ist Pin99 auf GND.