STM32F103 und CooCox, Anfängerfragen

[DAC (Gast)]

Hallo,

ich habe ein STM32F103C8T6-Board und CooCox installiert und möchte damit 
die sprichwörtliche LED zum Blinken bringen.

Ausserdem habe ich einen ST-Link V2 USB Programmer.

Meine erste Frage ist, wird das Programm nun mit dem ST-Link V2 auf den 
STM32 gebracht oder mit einem Micro-USB-Kabel (wie in manchen 
Beschreibungen)?

Falls beides geht ist die Verwendung des ST-Link V2 wahrscheinlich 
vorteilhafter (?).
Wenn dem so ist, wie wird der ST-Link mit dem STM32F103C8T6-Board 
verbunden?
So (?):

ST-Link   STM32
----------------
GND   ---> GND
SWCLK ---> CLK
SWDIO ---> IO
3.3V  ---> 3.3

[Markus S. (acepilot)]

Hi,

Wenn du Coocox inkl. der Toolchain komplett installiert hast, und 
ebenfalls alle Treiber für den STLinkV2 dann musst du nur noch wie 
selbst beschrieben den STLink mit deinem Board verwenden und das 
Programm übertragen. Ich an deiner Stelle würde auch den STLink 
verwenden, da mit diesem auch das Debuggen des Programmes möglich ist.

Gruß,
Markus

[DAC (Gast)]

Sehr gut, Danke!

Habe alles so gemacht wie beschriebenmit dem STLinkV2 und der Toolchain.

Nun blinkt auf dem Board die rote LED und die grüne LED (Power) leuchtet 
dauerhaft.

Die beiden Jumper stehen auf 0.
(wofür sind die eigentlich da?)


Unter "Respository/Peripherials" habe ich GPIO angeklickt, damit auf die 
Ports zugegriffen werden kann.

[Nico W. (nico_w)]

Also ich würde nicht mit einem totem Produkt noch anfangen.
Da musst du ja quasi Glück gehabt haben, dass die Coocox-Seite überhaupt 
aufrufbar war.

[Max M. (maxmicr)]

Nico W. schrieb:
> Also ich würde nicht mit einem totem Produkt noch anfangen.
> Da musst du ja quasi Glück gehabt haben, dass die Coocox-Seite überhaupt
> aufrufbar war.

Würde auch eher EmBitz empfehlen, gute Übersicht und angenehme Debugging 
Möglichkeiten (benutze auch den ST-Link V2 mit einem STM32F103).

[DAC (Gast)]

Dann werde ich jetzt auch EmBitz installieren und testen.
Gibt es irgendwo ein Beispielprogramm für eine blinkende LED o.ä. 
konkret für ein STM32F103?

[Stefan F. (Gast)]

Warscheinlich musst du am Target den Reset Knopf gedrückt halten. 
Während dessen kann sich der ST-Link mit dem µC verbinden. Nach dem 
Firmware-Upload musst du nochmal den Reset Knopf drücken, um die neue 
Firmware zu starten.

Dein ST-Link hat auch einen Reset Ausgang, den du mit dem Target 
verbinden kannst, um dies zu automatisieren.


Ja, hier: http://stefanfrings.de/stm32/index.html

[Arduinoquäler (Gast)]

Stefan U. schrieb:
> Warscheinlich musst du am Target den Reset Knopf gedrückt halten.

Nein.
Preisfrage: Warum hat ein Bluepill Board wohl nur 4 Anschlüsse
zum Debugger, nicht 5?

Stefan U. schrieb:
> Dein ST-Link hat auch einen Reset Ausgang,

Stefan U. schrieb:
> den du mit dem Target
> verbinden kannst, um dies zu automatisieren.

Preisfrage: Warum hat ein Bluepill Board wohl keinen Reset-
Anschluss zum Debugger herausgeführt? Um dem Benutzer das
Leben so schwer wie möglich zu machen? Oder weil es ohne auch
funktioniert?

[Stefan F. (Gast)]

Mein Hinweis bezieht sich auf das Bluepill Board an einem ST-Link v2.1. 
Ich musste bei meinen Versuchen häufig (aber nicht immer) den Reset 
Knopf drücken, damit sich der ST-Link verbinden kann.

[Arduinoquäler (Gast)]

Stefan U. schrieb:
> Mein Hinweis bezieht sich auf das Bluepill Board an einem ST-Link v2.1.

Warum schreibst du das dann nicht gleich dazu?

Bis zu deinem letzten Beitrag war hier nicht von einem
v2.1 die Rede.

Warum sollte man einen Reset Pin brauchen wenn in den
Konfigurations-Dialogen immer die Möglichkeit gegeben ist
einen Software System Reset auszulösen?

[grundschüler (Gast)]

DAC schrieb:
> Dann werde ich jetzt auch EmBitz installieren und testen.

Sei froh wenn coide funktioniert und lass es. Die Unterschiede der 
diversen ARM-ides sind für einen Anfänger unerheblich.

Versuch dein blinky. Es ist recht einfach pins initialisieren - nach 
coide-example -, Funktion für Sekundentakt, GPIOx->ODR-Register toggeln

[Stefan F. (Gast)]

> Mein Hinweis bezieht sich auf das Bluepill Board an einem ST-Link v2.1.
> Warum schreibst du das dann nicht gleich dazu?

Weil sowohl das Board als auch die Version des ST-Link keine Rolle 
spielen.

> Warum sollte man einen Reset Pin brauchen wenn in den
> Konfigurations-Dialogen immer die Möglichkeit gegeben ist
> einen Software System Reset auszulösen?

Während des Reset sind die Pins im SWD Modus. Nach dem Reset bestimmt 
die laufende Firmware, ob es sich um SWD oder GPIO Pins handelt.

> Warum hat ein Bluepill Board wohl keinen Reset-
> Anschluss zum Debugger herausgeführt?

Vielleicht:
Weil man es auch seriell Programmieren kann.
Weil Arduino User es üblicherweise per USB Bootloader programmieren.
Weil man die Reset Leitung dank Reset Taster nicht unbedingt braucht.
Weil das Board sonst breiter geworden wäre.

[Christopher J. (christopher_j23)]

Bei den ST-Link V2 mini ist normalerweise der Resetpin für STM8 gedacht, 
d.h. der funktioniert mit SWD sowieso nicht. Bei allen anderen ST-Links 
macht das durchaus auch Sinn mal die Reset-Leitung anzuschließen, z.B. 
wenn man sich ausgesperrt hat und einen "connect under reset" 
durchführen möchte.

[Arduinoquäler (Gast)]

Christopher J. schrieb:
> Bei allen anderen ST-Links
> macht das durchaus auch Sinn mal die Reset-Leitung anzuschließen, z.B.
> wenn man sich ausgesperrt hat und einen "connect under reset"
> durchführen möchte.

In diesem einzelnen seltenen Fall, wo man mal ausgesperrt
wurde, kann man auch den Reset per Hand betätigen, da kommt
man schon durch.

[DAC (Gast)]

Danke Grundschüler!

grundschüler schrieb:
> Sei froh wenn coide funktioniert und lass es. Die Unterschiede der
> diversen ARM-ides sind für einen Anfänger unerheblich.

EmBitz sieht schon beim Projekt-Anlegen äußerst kompliziert aus.


> Versuch dein blinky. Es ist recht einfach pins initialisieren - nach
> coide-example -, Funktion für Sekundentakt, GPIOx->ODR-Register toggeln

Wollte es so machen wie hier:

// Demo Blink-LED für STM32F4xx mit einem STM32F4DISCOVERY Board
// (c) 2013, Markus Müller
// Dieser Code darf frei verwendet, modifiziert und kopiert werden. Benutzung auf eigene Gefahr.
#include "stm32f4xx.h" // Deklaration der Peripheriefunktionen

void Delay(long i);

// Haupt-Programmschleife
int main(void)
{

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN; // Clock für Port D aktivieren

    GPIOD->MODER = 0x55000000; // Pin 12..15 als Ausgang deklarieren

    while(1) // Endlos SChleife
    {
        GPIOD->BSRRH = 0xF000; // Alle LEDs aus
        Delay(1000000);
        GPIOD->BSRRL = 0x1000; // LED 1 ein
        Delay(1000000);
        GPIOD->BSRRL = 0x2000; // LED 2 ein
        Delay(1000000);
        GPIOD->BSRRL = 0x4000; // LED 3 ein
        Delay(1000000);
        GPIOD->BSRRL = 0x8000; // LED 4 ein
        Delay(1000000);
    }
}

// Delay für Verzögerungen
void Delay(long i)
{
    volatile long iZ = i;
    while (iZ--);
}

Wie findet man unter CooCox die richtige .h-Datei fürs include# ?
(habe ja einen stm32f103 und keinen stm32f4xx)

Außerdem wollte ich Port A nehmen und nicht Port D, aber das ist 
wahrscheinlich trivial.

[Christopher J. (christopher_j23)]

Bei einem F1 nimmst du entsprechend stm32f1xx.h. Dieser bindet dann ein 
paar andere Header ein, etwa core_cm3.h für Funktionalität rund um den 
Prozessor selber und je nach gesetztem #define dann z.B. den für dich 
passenden stm32f103xb.h. Wie der #define aussehen muss findest du heraus 
wenn du mal in stm32f1xx.h hereinschaust aber für normal wird der bei 
solchen IDEs hinter deinem Rücken automatisch gesetzt wenn du ein 
Projekt für deinen Prozessor erstellst. Ich würde übrigens auch nicht 
unbedingt zu Coocox greifen. Das wird nicht mehr weiterentwickelt und 
die neueren Serien werden schon jetzt nicht mehr unterstützt. Mit 
SW4STM32 hast du eine IDE, die ebenso kostenlos ist (jedenfalls im 
Moment) und die quasi den Segen des Herstellers hat, d.h. sämtlichen 
Beispielcode von ST, egal ob SPL, HAL oder sonstwas  hast du direkt als 
Projektdatei vorliegen.

[grundschüler (Gast)]

GPIOD->MODER = 0x55000000; // Pin 12..15 als Ausgang deklarieren

sollte man so nicht machen da kryptisch (=nicht selbsterklärend)

üblich ist bei stm init über eine struct:

GPIO_InitTypeDef GPIO_InitStruct;

  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOE_CLK_ENABLE();

 /*Configure GPIO pin : led1_Pin */
  GPIO_InitStruct.Pin = led1_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  HAL_GPIO_Init(led1_GPIO_Port, &GPIO_InitStruct);

Das ist im Prinzip immer gleich, egal ob mit oder ohne HAL

Dein code setzt jetz nur das MODER-Register. Das entspricht dem
"  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;"
in der struct.


Du solltest dir die anderen in der struct aufgeführten Register im 
manual ansehen. Bei dir bleiben die unverändert, also =0. Kann richtig 
sein, mglw. aber auch nicht. Ich weiß das ohne Blick ins manual nicht.

Deswegen macht man es über eine struct, damit alle relevanten Register 
erfasst werden.

      GPIOD->BSRRH = 0xF000; // Alle LEDs aus

Im Prinzip willst du das OutputDataRegister ODR verändern. Steht darin 
1, ist der entsprechende Pin high sonst low.

Zusätzlich gibt es die Register BSRR -set- und BRR -reset- mit denen man 
einzelne Pins des ODR "maskiert" verändern kann. BRR ist identisch mit 
BSRRH BSRR mit BSRRL. Die beiden Register stehen hintereinander.

Geht also so, wie in deinem code. Wenn du dir die GPIO-Registern  im 
manual ansiehst, weißt du dazu noch was du machst. Am besten den 
GPIO-Teil ausdrucken um den blinky-code verstehen zu können.

[grundschüler (Gast)]

Christopher J. schrieb:
> Mit
> SW4STM32 hast du eine IDE, die ebenso kostenlos ist (jedenfalls im
> Moment) und die quasi den Segen des Herstellers hat, d.h. sämtlichen
> Beispielcode von ST, egal ob SPL, HAL oder sonstwas  hast du direkt als
> Projektdatei vorliegen.

Ich bin ja nun nicht unbedingt Anfänger. Mir ist die Installation von 
SW4 mit OpenOCD nicht gelungen. Das lag daran, dass bestimmte Versionen 
SW4/OpenOCD nicht zueinander passen. Coide wird mit STLink zusammen 
installiert, ist abgestimmt und läuft dann relativ sicher. Man kann auch 
HAL unproblematisch in Coide übernehmen. Vorteil von SW4 gegenüber Coide 
oder iregendwasanderem? Ich habe es noch nicht herausgefunden.

[Olaf B. (Firma: OBUP) (obrecht)]

grundschüler schrieb:
> Mir ist die Installation von
> SW4 mit OpenOCD nicht gelungen. Das lag daran, dass bestimmte Versionen
> SW4/OpenOCD nicht zueinander passen

Könnte sein, dass Du openocd V. 0.1.0 benötigst für ST4. Habe meins 
gerade auf 0.1.0 hochgezogen.

Vorteil:
  + SW4 wird weiter entwickelt >> Community-Projekt mit Unterstützung 
seitens ST
  + native Unterstützung sämtlicher STM32-µC & -Boards
  + basierend auf Eclipse >> viele Plugins verfügbar

mfg

Olaf

P.S.: lass Dir nicht einreden welche IDE Du benutzen sollst. Nimm die, 
die Dir zusagt. Auch wenn CoIDE anscheinend tot ist. Kann man später 
immer noch umsteigen. Meistens wird ein Projekt-Import angeboten oder 
per externen Makefile.

[Stefan F. (Gast)]

> Das ist im Prinzip immer gleich, egal ob mit oder ohne HAL

Nein, denn "das" ist Code, der die HAL verwendet.

> Mir ist die Installation von SW4 mit OpenOCD nicht gelungen.
> Das lag daran, dass bestimmte Versionen SW4/OpenOCD nicht
> zueinander passen.

Verstehe ich nicht. Diese Programme werden doch ein zusammenhängendes 
Paket zum Download angeboten, und das funktioniert ganz sicher. 
Vielleicht hast du von einer veralteten Quelle heruntergeladen. Richtig 
ist diese: 
http://www.openstm32.org/Downloading+the+System+Workbench+for+STM32+installer

> Vorteil von SW4 gegenüber Coide oder iregendwasanderem?

Funktioniert "einfach so", und wird von Cube/HAL ohne Einschränkung 
unterstützt.

[Pete K. (pete77)]

Alternativ könnte man auch sich mal Atollic TrueStudio anschauen.

[grundschüler (Gast)]

Stefan U. schrieb:
> Nein, denn "das" ist Code, der die HAL verwendet.

siehst du zwischen

static void GPIO_setup(void)
{RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

  GPIO_InitStruct.GPIO_Pin = GPIO_Pin_13 | GPIO_Pin_12;
     GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT;   
    GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; 
    GPIO_InitStruct.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL;   
    GPIO_Init(GPIOD, &GPIO_InitStruct);
}

und

/*Configure GPIO pins : PE2 key1_Pin key2_Pin */
  GPIO_InitStruct.Pin = GPIO_PIN_2|key1_Pin|key2_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

einen wesentlichen Unterschied?
      GPIO_Init(GPIOD, &GPIO_InitStruct); und
  HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);
sind offensichtlich gleiche Funktionen die gleiche Register setzen und 
sich nur durch den Funktionsnamen (Zusatz HAL_) leicht unterscheiden.

[Stefan F. (Gast)]

Ok, hast mich überzeugt. Jetzt verstehe ich, wie du das gemeint hast.

[Dumpfbacke (Gast)]

Pete K. schrieb:
> Alternativ könnte man auch sich mal Atollic TrueStudio anschauen.

Welches genau so wie CooCoox nach Hause telefoniert und wer
weiss was alles vom Rechner abholt.

Ich staune immer wieder mit welcher "Robustheit" (sollte man
Ignoranz sagen, sollte man Naivität sagen?) diese Dinge
übersehen werden .....

[Pete K. (pete77)]

Dumpfbacke schrieb:
> Pete K. schrieb:
>> Alternativ könnte man auch sich mal Atollic TrueStudio anschauen.
>
> Welches genau so wie CooCoox nach Hause telefoniert und wer
> weiss was alles vom Rechner abholt.
>
> Ich staune immer wieder mit welcher "Robustheit" (sollte man
> Ignoranz sagen, sollte man Naivität sagen?) diese Dinge
> übersehen werden .....

Belege für Atollic?

[Stefan F. (Gast)]

Solange beim Daten-Schnorcheln nichts schlimmes passiert, wird eine 
zunehmende Anzahl von Benutzern die Vorzüge von "kostenlos" genießen, 
ohne großartige darüber nachzudenken.

Der Begriff "Privatsphäre" verliert zunehmend an Bedeutung. Am meisten 
legen Leute darauf wert, die sich in der Vergangenheit durch eine 
feindliche Bedrohung verfolgt fühlten.

In diesem Land werden wir zwar mehr denn je ausspioniert, aber zumindest 
gefühlt nicht auf feindliche Art, sondern auf Kommerzielle Art und zum 
Schutz. Insofern ist der sinkende Bedarf nach Privatsphäre nur 
verständlich.

[DAC (Gast)]

Vielen Dank für die vielen guten Antworten, besonders an Grundschüler!

Habe nun bei CooCox ein fertiges Projekt geladen und compiliert.

Dann wollte ich das Programm mit F5/Strg auf den Controller laden, 
bekomme aber die Fehlermeldung

Erase:   Done
Program:   Failed
Error: Flash driver function execute error
Program Download Failed !

Woran kann das liegen?


Der ST-Link V2 hat übrigens die aktuelle Firmware aufgespielt.

[Stefan F. (Gast)]

Hast du probiert, den Reset Knopf zu drücken, während der ST-Link die 
Verbindung zum µC aufbaut?

[DAC (Gast)]

Wenn ich Reset dauerdrücke und F5/Strg drücke, gehen die grünen Balken 
schon mal weiter als vorher. Dann bleiben sie aber stehen und nach einer 
Zeit kommt die Fehlermeldung:

Error: Flash driver function execute timeout
Erase:  [  0%]pc: 0x200007fc
Program Download Failed !


Wenn Reset nur am Anfang gedrückt wird, Fehlermeldung wie weiter oben.
Muss vielleicht irgendetwas anders eingestellt werden?
Im Moment ist auch nur der ST-Link V2 am STM32F103-Board angeschlossen 
(der Micro-USB-Port vom Board ist leer)

[Stefan F. (Gast)]

Benutze in deiner Software, die den ST-Link ansteuert die Option 
"Connect under Reset". Drücke und halte den Reset Knopf des µC. Klicke 
dann auf den Button, der den Lösch- oder Programmiervorgang startet. 
Lasse sofort danach den Reset Knopf wieder los.

https://www.youtube.com/watch?v=jEz0C2bT2M0

[DAC (Gast)]

Danke!

"Connect under Reset" finde ich mit dieser Bezeichnung nicht, siehe 
Screenshot...

Video schaue ich mir gleich an.

[grundschüler (Gast)]

Sschreibschutz deaktiviert? jumper richtig gesetzt?

[grundschüler (Gast)]

schau mal hier:
Beitrag "stm32f103c8 lässt sic nich flashen"

[Stefan F. (Gast)]

> "Connect under Reset" finde ich mit dieser Bezeichnung nicht

Versuche HWRESET, vielleicht ist dieses Setting auch egal, wenn du den 
Reset Knopf manuell betätigst.

[Stefan F. (Gast)]

Eigentlich müsste hier doch der Arduinoquäler schnell und zielsicher 
helfen können, nach seinen obigen Äußerungen zur nicht nötigen NRST 
Leitung.

SCNR

[DAC (Gast)]

Die Symptome sind wie hier im Video gezeigt ( ab ca. 9:17 ):

Youtube-Video "Short Tutorial: How To Start Programming STM32 Arduino 
MCUs"

Vermutlich ist der Lese- und Schreibschutz aktiviert.

Mit dem Programm 'Flash Loader Demonstrator' von ST (s. Video) müsste 
man das Problem eigentlich beheben können (Schreibschutz deaktivieren).

Das Programm habe ich auch installiert. Bekomme aber keinen Kontakt zum 
Board (sobald ich es über USB anschließe, versucht Win7 einen Treiber 
runterzuladen, was nicht klappt - und dadurch gibt es möglicherweise 
Probleme mit dem 'richtigen' Treiber?!).

[Markus (Gast)]

//Stefan U. schrieb:
//> Nein, denn "das" ist Code, der die HAL verwendet.

//siehst du zwischen

static void GPIO_setup(void)
{RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

  GPIO_InitStruct.GPIO_Pin = GPIO_Pin_13 | GPIO_Pin_12;
     GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT;   
    GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; 
    GPIO_InitStruct.GPIO_OType = GPIO_OType_PP;
    GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL;   
    GPIO_Init(GPIOD, &GPIO_InitStruct);
}


und

/*Configure GPIO pins : PE2 key1_Pin key2_Pin */
  GPIO_InitStruct.Pin = GPIO_PIN_2|key1_Pin|key2_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);


//einen wesentlichen Unterschied?
      GPIO_Init(GPIOD, &GPIO_InitStruct); und
  HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);
//sind offensichtlich gleiche Funktionen die gleiche Register setzen und 
//sich nur durch den Funktionsnamen (Zusatz HAL_) leicht unterscheiden.

Oh Jehova, gelobt sei Arduino, denn er erspart uns derer viele Qual.

[grundschüler (Gast)]

ich habe es seinerzeit mittels eines usb/usart-adapters geschafft. Ich 
meine, der usb-anschluss auf dem board ist nicht für den usart - bin mir 
da aber nicht sicher.

[Christopher J. (christopher_j23)]

Stefan U. schrieb:
> Benutze in deiner Software, die den ST-Link ansteuert die Option
> "Connect under Reset".

Stefan U. schrieb:
> Versuche HWRESET

Wenn ich das richtig verstanden habe, dann hat der TO einen von diesen 
ST-Link V2 Mini USB-Dongles. Wie ich oben schon geschrieben hatte 
funktioniert bei denen der (Hardware-)Reset per Resetleitung für die 
STM32 nicht, der funktioniert nur für STM8 und bei STM32 kommt es 
dadurch unweigerlich zu Timeouts wenn man in irgendeiner Art und Weise 
versucht einen Hardware-Reset durchzuführen.

Wie man einen manuellen "connect under reset" durchführt hatte ich mal 
hier beschrieben: Beitrag "Re: NUCLEO STM32F411"

tldr;

Man muss den Resetknopf auch wieder loslassen (in etwa binnen 2 Sekunden 
nach Start des Flashvorgangs), sonst gibt es unweigerlich einen Timeout.


DAC schrieb:
> Das Programm habe ich auch installiert. Bekomme aber keinen Kontakt zum
> Board (sobald ich es über USB anschließe, versucht Win7 einen Treiber
> runterzuladen, was nicht klappt - und dadurch gibt es möglicherweise
> Probleme mit dem 'richtigen' Treiber?!).

Per USB geht das sowieso nicht. In die USB-Buchse vom Rechner gehört nur 
der ST-Link und den verbindest du wie in deinem Eingangspost geschrieben 
mit dem Blue-Pill Board.

[DAC (Gast)]

Ich formuliere es mal anders rum.

Wenn der ST-Link V2 nicht angeschlossen ist und das STM32F103-Board nur 
über USB mit dem Rechner verbunden wird, kommt von Win7 die 
Fehlermeldung
"USB-Gerät wurde nicht erkannt"

Frage: benötigt das STM32F103-Board selber noch einen speziellen 
Windows-Treiber?

[STM Apprentice (Gast)]

DAC schrieb:
> Wenn der ST-Link V2 nicht angeschlossen ist und das STM32F103-Board nur
> über USB mit dem Rechner verbunden wird, kommt von Win7 die
> Fehlermeldung "USB-Gerät wurde nicht erkannt"

Das ist normal denn auf dem STM32F103-Board läuft ja aktuell
keine Firmware die den USB-Port bedient.

DAC schrieb:
> Frage: benötigt das STM32F103-Board selber noch einen speziellen
> Windows-Treiber?

Nein, erst wenn du eine spezifische USB-Firmware laufen lässt.
Das wäre dann meistens der Virtual Com Port Driver von STM.

[DAC (Gast)]

Danke für die Postings!

Hat sich jetzt etwas überschnitten.

>Nochmal der Ablauf:
>
>1. Reset drücken und halten
>2. OpenOCD starten (per Kommandozeile oder IDE)
>3. Reset loslassen (binnen etwa zwei Sekunden)
>
>Fertig.

Das funktioniert leider nicht.

Sowohl CooCox als auch STM32 ST-Link Utility machen Stress.



grundschüler schrieb:
> ich habe es seinerzeit mittels eines usb/usart-adapters geschafft. Ich
> meine, der usb-anschluss auf dem board ist nicht für den usart - bin mir
> da aber nicht sicher.

Ach so. Ein USB-to-UART-Modul (virtueller Com-Port) habe ich hier. Wie 
wird der virtuelle COM-Port dann an das STM32-Board angeschlossen? RX an 
IO und TX an SCK???



STM Apprentice schrieb:
> Nein, erst wenn du eine spezifische USB-Firmware laufen lässt.
> Das wäre dann meistens der Virtual Com Port Driver von STM.

Habs kapiert, Danke!

[DAC (Gast)]

DAC schrieb:
> grundschüler schrieb:
>> ich habe es seinerzeit mittels eines usb/usart-adapters geschafft. Ich
>> meine, der usb-anschluss auf dem board ist nicht für den usart - bin mir
>> da aber nicht sicher.
>
> Ach so. Ein USB-to-UART-Modul (virtueller Com-Port) habe ich hier. Wie
> wird der virtuelle COM-Port dann an das STM32-Board angeschlossen? RX an
> IO und TX an SCK???

Wobei, welche Pegel kommen aus dem USB-to-UART-Modul? Das Modul selber 
läuft ja mit 5V (hat aber auch 3,3V als Ausgang).

[Christopher J. (christopher_j23)]

DAC schrieb:
>>Nochmal der Ablauf:
>>
>>1. Reset drücken und halten
>>2. OpenOCD starten (per Kommandozeile oder IDE)
>>3. Reset loslassen (binnen etwa zwei Sekunden)
>>
>>Fertig.
>
> Das funktioniert leider nicht.
>
> Sowohl CooCox als auch STM32 ST-Link Utility machen Stress.

Ich kenne mich mit den Befindlichkeiten vom ST-Link Utility und dessen 
Interaktion mit Coocox nicht aus. Es kann sein, dass es daran liegt, 
dass die Protection-Bits gesetzt sind. Wie man die mit ST-Link Utility 
löscht (Stichwort "mass erase") kann ich dir nicht genau sagen. Wurde 
hier im Forum an anderer Stelle aber schon öfters diskutiert. Ansonsten 
würde ich wie oben schon erwähnt einfach zu SW4STM32 greifen und OpenOCD 
nutzen.


DAC schrieb:
> grundschüler schrieb:
>> ich habe es seinerzeit mittels eines usb/usart-adapters geschafft. Ich
>> meine, der usb-anschluss auf dem board ist nicht für den usart - bin mir
>> da aber nicht sicher.
>
> Ach so. Ein USB-to-UART-Modul (virtueller Com-Port) habe ich hier. Wie
> wird der virtuelle COM-Port dann an das STM32-Board angeschlossen? RX an
> IO und TX an SCK???

Der USB-Anschluss auf dem Board ist für USB. Da kann man wenn man will 
einen virtuellen COM-Port draus machen, dann verhält sich das USB-Gerät, 
als würde es an einem COM-Port stecken, sozusagen ein emulierter UART. 
Hast du einen USB-to-UART Converter, dann gehört der auf Seite des STM32 
auch an RX und TX des UARTs und nirgendwo sonst hin, erst recht nicht an 
die SWD-Pins. Flashen kann man damit prinzipiell auch und zwar über den 
eingebauten UART-Bootloader.

[STM Apprentice (Gast)]

DAC schrieb:
> Wie
> wird der virtuelle COM-Port dann an das STM32-Board angeschlossen? RX an
> IO und TX an SCK???

Nein, an eines der Rx/Tx Pärchen von denen es drei gibt,
z.B.  Rx an PA9, Tx an PA10, und Masse nicht vergessen.

[DAC (Gast)]

Danke Christopher für die ausführliche Antwort!

Christopher J. schrieb:
> Ansonsten
> würde ich wie oben schon erwähnt einfach zu SW4STM32 greifen und OpenOCD
> nutzen.

Du meinst das hier?
http://www.openstm32.org/HomePage
Und damit kann man sicher die Protection-Bits löschen?



STM Apprentice schrieb:
> Nein, an eines der Rx/Tx Pärchen von denen es drei gibt,
> z.B.  Rx an PA9, Tx an PA10, und Masse nicht vergessen.

Danke für den wichtigen Hinweis! Was ist mit den Pegeln, benötigt man 
noch einen Pegelwandler von 5V auf 3.3V? Oder liegt der Ausgangspegel 
automatisch bei 3,3V, wenn man vom USB2UART-Modul nicht die 5V-Leitung 
sondern die 3,3V-Leitung ans STM32-Modul anschließt?

[Stefan F. (Gast)]

> Oder liegt der Ausgangspegel automatisch bei 3,3V

Kommt auf dein USB-UART Modul an. Die meisten laufen fest mit 3,3V oder 
mit 5V. Messe doch einfach nach, welche Spannung am Tx Pin anliegt.

[Christopher J. (christopher_j23)]

Hier bekommst du das direkt zum Download:
http://www.ac6-tools.com/downloads/SW4STM32/

Protection Bits löschen kann OpenOCD und das sollte da mit drin sein.

Wie es geht steht zum Beispiel hier:
Beitrag "Re: STLINK V2 und China Boards"

Es geht auch garantiert mit dem ST-Link Utility. Musst halt mal suchen. 
Ich kenne mich damit wie gesagt nicht aus.

[STM Apprentice (Gast)]

DAC schrieb:
> Was ist mit den Pegeln,

Zeig doch dein Modul, und schau im Datenblatt nach.

[DAC (Gast)]

Die Pegel vom USB2UART-Modul (TX) liegen bei 3,4V.


Habe es so angeschlossen wie von STM Apprentice beschrieben:

STM Apprentice schrieb:
> Nein, an eines der Rx/Tx Pärchen von denen es drei gibt,
> z.B.  Rx an PA9, Tx an PA10, und Masse nicht vergessen.

Der linke Jumper (der bei CN1) musste dann noch von 0 auf 1 gestellt 
werden.


Und dann konnte ich endlich mit 'STM Flash Loader Demo' den 
Schreibschutz entfernen, puh.


Dann Jumper wieder zurück auf 0 und dann konnte anscheinend fehlerfrei 
das hex auf den Controller geflasht werden (mit CooCox).

Genauer überprüft wird es morgen.



Jetzt schon mal ein riesengroßes Danke !!! an alle, die mitgeholfen 
haben!!!!!

[STM Apprentice (Gast)]

DAC schrieb:
> Habe es so angeschlossen wie von STM Apprentice beschrieben:

Ja fürs Programmieren muss man sogar RX1/TX1 verwenden,
die anderen funktionieren dafür nicht ....

Gratuliere zum Erfolg den du dir offensichtlich auch teilweise
selbst erarbeitet hast.

[Stefan F. (Gast)]

Welches konkrete Board ist das denn?
Ich würde die Sache mit dem Schreibschutz gerne in meine STM32 Notizen 
aufnehmen.

[STM Apprentice (Gast)]

Stefan U. schrieb:
> Welches konkrete Board ist das denn?

Ich dachte wir reden hier die ganze Zeit vom Bluepill.
Siehe Rx/Tx Pins.

DAC schrieb:
> ich habe ein STM32F103C8T6-Board

Sehr unwahrscheinlich dass es etwas anderes ist ....

[Stefan F. (Gast)]

> Ich dachte wir reden hier die ganze Zeit vom Bluepill

Ich auch, aber ich möchte sicher sein, denn der TO hat es nicht konkret 
benannt.

[DAC (Gast)]

Stefan U. schrieb:
> Welches konkrete Board ist das denn?

Ein STM32F103C8T6-Board. Ich glaube, das hier hatte ich konkret gekauft:
http://www.ebay.de/itm/GOOD-STM32F103C8T6-ARM-STM32-System-Development-Board-40-Pin-For-Arduino-TE435/282013850446?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
(GOOD STM32F103C8T6 ARM STM32 System Development Board 40 Pin For 
Arduino TE435)



STM32F103C8T6-Board = Bluepill?

[Stefan F. (Gast)]

Das ist ein Bluepill Board.

Es gibt auch andere Boards mit dem selben Mikrocontroller. Das 
Maple-Mini Board ist zum Beispiel eins mit sehr ähnlichem Format.

[DAC (Gast)]

Hat der STM32F103 eigentlich keine Pullup-Widerstände eingebaut (so wie 
ein AVR)?

[STM Apprentice (Gast)]

DAC schrieb:
> Hat der STM32F103 eigentlich keine Pullup-Widerstände eingebaut (so wie
> ein AVR)?

Genau so programmierbar wie ein AVR.
Input, Output, Pullup, Pulldown, Open Drain ....

[Stefan F. (Gast)]

> Hat der STM32F103 eigentlich keine Pullup-Widerstände eingebaut

Haben sie, warum fragst du das?

[DAC (Gast)]

Stefan U. schrieb:
>> Hat der STM32F103 eigentlich keine Pullup-Widerstände eingebaut
>
> Haben sie, warum fragst du das?

Weil ich hier einen Schaltplan habe, bei dem an jeder Daten-Leitung 10k 
nach +Ub hängen (wohl gemerkt externe Widerstände).

[STM Apprentice (Gast)]

DAC schrieb:
> Weil ich hier einen Schaltplan habe, bei dem an jeder Daten-Leitung 10k
> nach +Ub hängen

Das kann andere Gründe haben. Manche Schaltungen brauchen einen
definierten Zustand wenn der Prozessor noch nicht initialisiert
ist (und damit seine Pull-Programmierung noch nicht wirkt).

Zeige den Schaltplan.

[Stefan F. (Gast)]

Die internen Pull-Up Widerstände haben ungefähr 40k Ohm, vielleicht 
wollte der Autor weniger Ohm haben.

[DAC (Gast)]

Der Autor wollte tatsächlich weniger als 40k haben.


Habe noch eine Frage zur Spannungsversorgung. Kann man bei dem 
Bluepill-Board einfach 5V an dem 5V-Anschluss (der zwischen B9 und GND) 
anschließen, damit es läuft?

(momentan hängt es noch am USB-Port)

[STM Apprentice (Gast)]

DAC schrieb:
> Kann man bei dem
> Bluepill-Board einfach 5V an dem 5V-Anschluss (der zwischen B9 und GND)
> anschließen, damit es läuft?

Das kannst du dem Schaltplan entnehmen. Der 5V Pin ist direkt
mit der USB-Versorgung verbunden. Also Entweder USB Versorgung
nutzen, oder extern 5V einspeisen. Aber nicht 5V einspeisen und
gleichzeitig USB benutzen!

[DAC (Gast)]

Kann ich auch einfach die 5V-Leitung der USB-Buchse abklemmen (also 
unterbrechen) und das Board extern mit 5V betreiben und dann im 
Bedarfsfall den USB-Stecker einstecken (während die externen 5V in 
Betrieb sind)?

[Einer K. (Gast)]

2 (schottky) Dioden, und du bist der König!

[Stefan F. (Gast)]

> Aber nicht 5V einspeisen und gleichzeitig USB benutzen!

Ein kleiner aber wichtiger Unterschied zum Arduino Nano.

> Kann ich auch einfach die 5V-Leitung der USB-Buchse abklemmen

Da bin ich jetzt nicht 100% sicher, aber cih denke, das geht. Was aber 
passiert, wenn du das Modul per USB mit einem PC verbindest, während die 
Stromversorgung noch nicht eingeschaltet ist? Da müsste man mal ganz 
genau in das Datenblatt schauen.

Wenn diese beiden Datenleitungen 5V tolerant sind, sollte nichts kaputt 
gehen
(denn dann hängt die maximale Eingangsspannung nicht von VCC ab, da sie 
keine klassischen ESD Dioden nach VCC haben). Wenn es aber 3,3V 
Leitungen sind, dann war es keine gute Idee.