Hier ein paar Grundsätzliche Sachen die man beim benutzen der CooCox-IDE beachten sollte.
Hinweis : meine Librarys vom STM32F4 bauen auf den “standard peripherals” von ST auf.
Dazu ist CoIDE Version V:1.7.8 notwenig (nicht die Beta V:2.x.x).
Alternativer Downloadlink bei web.archive.org.
1. Falsche externe Quarz-Einstellung
2. Fehlende Initialisierung vom System-Clock
3. Test der Clock Einstellung
4. Vorlagen für Main.c und Main.h
5. Einbinden von neuen Librarys
6. Debug Ausgabe direkt über die IDE (ohne UART)
1. Falsche externe Quarz-Einstellung :
Beim erstellen eines neuen Projektes mit CooCox werden automatisch einige Files in den eigenen Projektordner kopiert. Diese Files sind für den Bootvorgang und die Starteinstellungen der STM32F4 CPU notwendig.
Jetzt ist es leider so, das bei den original Files von CooCox von einem externer Quarz mit 25MHz ausgegangen wird. Auf dem SMT32F4-Dicovery-Board ist aber nur ein 8MHz Quarz eingebaut. Mit diesen Einstellungen läuft die CPU damit langsamer als gewünscht.
Um dieses Problem zu beheben, kann man jetzt etweder jedesmal nach dem erstellen von einem Projekt die entsprechenden Files anpassen (bzw ersetzen). Oder man überschreibt einmal die original Files von der CooCox Installation und bekommt dann automatisch jedesmal bei einem neuen Projekt die richtigen Einstellungen.
Hier die zwei Files um die es geht im eigenen Projekteordner :
1 2 | cmsis_boot/stm32f4xx.h cmsis_boot/system_stm32f4xx.c |
diese werden beim erstellen eines Projektes aus diesem Pfad kopiert :
1 | C:\CooCox\CoIDE\repo\Components\500_CMSIS BOOT\src\cmsis_boot\ |
hier sind die zwei abgeänderten Files mit der Einstellung auf 8Mhz externem Quarz :
2. Fehlende Initialisierung vom Systemclock :
Ein zweiter “Fehler” der CooCox standard Files ist, das die CPU nach dem booten mit dem internen 16MHz Quarz arbeitet “HSI” und nicht auf den externen Quarz mit PLL umgeschaltet wird “PLL”.
Um das zu umgehen, muss in der “Main.c” diese Funktion gestartet werden :
1 | SystemInit(); |
damit wird der Systemclock umgestellt und die CPU läuft danach mit 168MHz.
3. Test der Clock Einstellung :
Ob der Clock richtig eingestellt ist, kann man testen, indem man den Systemclock
am Pin PC9 per Oszi nachmisst. Hier ein Stück Code damit an PC9 der Sysclock ausgegeben wird :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | void check_sysclock(void) { GPIO_InitTypeDef GPIO_InitStructure; // Clock Enable RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE); // Config PC9 (MCO2) als AF GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF; GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &GPIO_InitStructure); // Sysclock an PC9 ausgeben RCC_MCO2Config(RCC_MCO2Source_SYSCLK, RCC_MCO2Div_1); GPIO_PinAFConfig(GPIOC, GPIO_PinSource9, GPIO_AF_MCO); } |
nach dem Aufruf der Funktion muss an PC9 ein 168MHz Signal liegen.
Dann ist alles Ok. (falls euer Oszi nicht so hoch messen kann einfach den
Vorteilerwert “RCC_MCO2Div_1″ abändern.
4. Vorlage für “Main.c” und “Main.h” :
Ich habe mir für das “Main.c” und “Main.h” File eine Vorlage erstellt, die ich immer bei einem neuen Projekt benutze.
Das “Main.c” sieht so aus :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | //-------------------------------------------------------------- // File : main.c // Datum : 01.01.2013 // Version : 1.0 // Autor : UB // EMail : mc-4u(@)t-online.de // Web : www.mikrocontroller-4u.de // CPU : STM32F4 // IDE : CooCox CoIDE 1.7.0 // Module : CMSIS_BOOT, M4_CMSIS_CORE // Funktion : Hauptprogramm // Hinweis : Diese zwei Files muessen auf 8MHz stehen // "cmsis_boot/stm32f4xx.h" // "cmsis_boot/system_stm32f4xx.c" //-------------------------------------------------------------- #include "main.h" int main(void) { SystemInit(); // Quarz Einstellungen aktivieren while(1) { } } |
und das “Main.h” sieht so aus :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | //-------------------------------------------------------------- // File : main.h //-------------------------------------------------------------- //-------------------------------------------------------------- #ifndef __STM32F4_UB_MAIN_H #define __STM32F4_UB_MAIN_H //-------------------------------------------------------------- // Includes //-------------------------------------------------------------- #include "stm32f4xx.h" //-------------------------------------------------------------- #endif // __STM32F4_UB_MAIN_H |
Beide Files sind hier als ZIP :
5. Einbinden von neuen Librarys :
Damit der Quellcode durch eigene Librarys (bzw. die Librarys von diesen Seiten) übersichtlich bleibt, hab ich mir folgende Vorgehensweise angewöhnt.
Nach dem anlegen eines neuen Projektes, erstelle ich im Projekteordner einen neuen Unterordner z.B. mit dem Namen “ub_lib” (siehe Bild)
Projekt mit “ub_lib” Unterordner
Dorthinein kopiere ich alle Library C- und H-Files die ich benutzen will. Am Beispiel der LED-Library sieht das dann so aus :
Inhalt von “ub_lib”
Die Files von diesem Unterordner müssen dann noch bei CoIDE hinzugefügt werden. Auch hier erstelle ich zuerst einen neuen Unterordner per rechter Maustaste und “Add Group” und wieder dem Namen “ub_lib”
Unterordner “ub_lib” in CoIDE
Und dann mit rechter Maustaste und “Add Files” die Files aus dem Unterordner hinzufügen.
Hinzugefügte Files
So bleibt der Projektordner aufgeräumt und übersichtlich.
Um die Funktionen der LED-Library im Main benutzen zu können ,
muss natürlich noch diese Zeile im Main.c Kopf eingefügt werden :
1 | #include "stm32_ub_led.h" |
6. Debug Ausgabe direkt über die IDE (ohne UART) :
Wer für Debug-Zwecke ein “printf” braucht und keine extra UART
und Kabel benutzen will, kann seine Ausgaben auch direkt über CoIDE
anzeigen lassen.
Ich gehe mal von einem neuen (leeren) Projekt aus (nur mit GPIO) :
Als erstes muss “Semihosting” über die “Repository” von CoIDE hinzugefügt werden :
CoIDE aktiviert automatisch noch zusätzlich “C-Library” und “retarget printf”
Jetzt muss in der “Configuration” unter “Debugger” das “Semihosting”
noch freigegeben werden :
Bei der Ausgabe gibt es jetzt zwei Möglichkeiten.
Wem einfache Texte (ohne Variablenausgabe) reichen,
fügt einfach einen Include ein und kann dann direkt die Funktion
“SH_SendString” benutzen :
Variabeln und Zahlen müssen in diesem Fall per “sprintf”
zuvor in einen String umgewandelt werden.
Wem das zu Umständlich ist, kann folgendes machen :
1. Das File “printf.c” öffnen, das im eigenen Projektordner liegt
2. ganz oben den include von “semihosting.h” hinzufügen
3. in der Funktion “PrintChar” den Aufruf “SH_SendChar” einfügen
Jetzt kann im eigenen Programm durch einen Include
die normale “printf” Funktion mit Parameterübergabe
benutzt werden :
Das eigentliche Anzeigen der Debug-Ausgabe funktioniert dann
indem man das Programm per “F5 = StartDebug” laufen lässt
und sich rechts unten die Registerkarte “Semihosting” anzeigen lässt :
Eine einfache Eingabe über den PC funktioniert auch,
indem man mit der Funktion “SH_GetChar” einzelnde Zeichen
vom User über die Tastatur abholen kann :
(die Taste “Return” muss nach der Eingabe vom Zeichen gedrückt werden)
23 Antworten auf Grundsätzliches zur CooCox-IDE
Wie hat Dir dieser Artikel gefallen?
(Noch keine Bewertungen)
Loading...
didi 
admin_mb
Kann es sein, dass man bei Coocox nicht zwei Projekte gleichzeitig offen haben kann? Ich habe mehrere unterschiedliche Projekte. Ab und zu mache ich sowas wie eine sicherheits kopie, ich kopiere den Ordner und schreibe weiteren Code. Manchmal will ich aber aus einem Projekt geschriebenen Code kopieren. Die Schwierigkeit hier ist zwischen den Projekten hin und her zu wechseln. Kannst du mir ein Tipp geben?
Gruß
Bei CoIDE kann immer nur ein Projekt geöffnet sein. Aber du kannst einzelne Files per “File/Open file…” zusätzlich öffnen. Diese werden dann nicht in das Projekt hinzugelinkt du kannst sie aber trotzdem bearbeiten (also Copy/Paste usw). Vielleicht reicht dir das ja.
Es gibt Abhilfe in Form eines einfachen Hacks: Lösche einfach die Datei
C:\CooCox\CoIDE\configuration\ProgramData\.singleton_coide
nach dem Start der ersten Instanz, dann kannst Du eine zweite aufmachen.
Von den Autoren wurde mal in Aussicht gestellt, sie würden in Version 2 wieder mehrere Instanzen erlauben, aber ich hab die aktuelle Beta der Version 2 noch nicht ausprobieren wollen.
Hallo,
ich muss vor die SystemInit() Funktion noch die Funktion init() aufrufen. Mache ich das nicht, bleibt die LED dunkel. Ich habe das LED Blinkbeispiel von dieser Seite genommen und einfach die SystemInit eingefügt.
Gruß
Kai
das Blinkbeispiel von welcher Seite ? … auf dieser Seite hier geht es nur um die Einstellungen für die CooCox-IDE.
Eine Funktion “init()” gibt es nicht, du meinst wahrscheinlich “UB_Led_Init()” und ein komplettes Beispiel dafür steht auch online.
Ich habe das Beispiel von der Seite “Installation der Toolchain und erstes Projekt” verwendet und meinen Fehler schon gesehen (man ist mir das peinlich). Die dortige init Funktion initialisiert die LED Ports.
Ist doch kein Problem. Nur durch Fehler machen, finden und beseitigen kann man was lernen.
Hallo,
erstmal danke für die ganzen Beispiele.
Wie kann man die ganzen 192 KB interne SRAM des F407 nutzen und draufzugreifen?
Danke, Markus
Im Linker script von CoIDE ist der komplette RAM-Bereich von 192k eingetragen. Aufgeteilt in zwei Blöcke : “ram=128k” und “ram1=64k”. Undefinierte Variabeln landen im 128k Block. Um eine Variable in den 64k Block zu legen musst du das dem linker sagen :
uint32_t buffer[10] __attribute__((section(".ram1")));Hallo,
kann man mit der CooCox den Code auch aus dem RAM heraus laufen lassen?
Ist das notwendig? Mich würde interessieren ob das sinnvoll ist. Da ich ziemlich viel am flashen bin, weil ich viel herumexperimentiere ohne konkretes Ziel, habe ich etwas bedenken, dass ich die 10000 Schreibzyklen schnell erreiche. Ich habe bereits eine Anfrage in einem Forum gestellt und einen Link geschickt bekommen. Leider bezieht sich dieser nicht auf CooCox. Deshalb wollte ich hier einmal nachfragen.
Gruß
Kai
also ich programmiere auch viel und mach mir darüber gar keine Gedanken. Aber du kannst bei CoIDE unter “Configuration/Link” auf den Punkt “Debug in RAM” umstellen. Dann nach dem compilieren nicht “download code to flash” sondern mit “start debug” das Programm starten. Aber dazu muss das auch ins RAM passen
. Einfacher ist, nach jedem Tag den du programmiert hast 10 Cent in ein Glas zu werfen, wenn das Flash defekt ist, hast du genug Geld für ein neues Disco-Board.
Hast du denn noch keine Probleme gehabt, mit den Schreibzyklen, seitdem Du das STM32F4 Discovery hast?
Ich habe das mit dem Debug ausprobiert. Das Programm wird zwar ausgeführt, allerdings wenn ich Änderungen am Code mache und dann kompiliere und dann debug drücke übernimmt er irgendwie nicht die Änderungen, die ich gemacht habe, sondern führt irgendwie die Version, die vorher gebrannt wurde.
Mache ich was falsch?
Ich habe noch nie von Problemen damit gehört. Du wirst bei 10 Cent pro Tag wohl bei einen luxuriöseren Board als beim F4 Disc. landen
Ok, alles klar. Habe auch schon 20 Cent.
Hi
Thank you for all examples.
Weil mir gerade zwei Dateien im Projekt “abhanden” gekommen sind…
zu 5.) 5. Einbinden von neuen Librarys :
Wirklich ERST die Datei im Explorer in den gewünschten Pfad kopieren
DANACH erst die Datei im Prjekt adden. Sonst gibt es kuddelmuddel, wenn ihr das Projekt auf einem anderen Rechner öffnen wollt und die Datei vom Typ “linked” ist.
Auch bei “NEW FILE” sollte man immer genau prüfen, wo man sich in der Ordnerstruktur befindet.
Auf das man immer alle Dateien dabei hat, wenn man seinen Workspace zippt und “mitnimmt”.
Viele Grüße und viel Spaß
Axel DG1RTO
Hallo
Habe eine Frage: Wenn ich eine C-File habe, muss ich um dieses zu Testen jedes Mal ein neues Projekt erstellen. Danke
Gruß
ein C-File alleine kannst du nicht in die CPU flashen.
verstehe die Frage nicht ganz.
Ich habe die CoIDEV2Beta installiert, gibt es zu dieser Version bekannte Bugs oder bekannte Probleme im Umgang mit dem STM32F407?
Da es ja mit dem F429, nicht gerade kompatibel ist, außer man verwendet die auf der Webseite aufgezeigten kniffe.
Danke
die Beta kenne ich nicht (aber Beta sagt ja eigentlich schon alles aus
ich würde Dir zur Version 1.7.8 raten, die unterstützt auch den F429.
Achtung, Coocox 2 beta nutzt offenbar nicht mehr die Standard Peripheral Library sondern STM32Cube mit HAL -> ohne Änderungen nicht kompatibel zu dem Code hier… Weiteres bei den Kommentaren zu STM32F429 hier: http://mikrocontroller.bplaced.net/wordpress/?page_id=2708
ich habe deine Kommentare gelöscht, die Beschreibung kann abgekürzt werden. Wer meine Librarys hier unter Coocox benutzen will, muss zwingen die CoIDE 1.7.8 installieren. Mit der Beta funktioniert es nicht.
Bedarf es bei der 1.7.8 immer noch dem hier gezeigten Linker Script oder wird der 429 nun voll unterstützt wenn man ihn direkt auswählt beim Anlegen eines Projekts?